From FORRERJ@frl.orst.edu Tue Jan 03 10:53:15 1995 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxPCTw-OOO1FNC; Tue, 3 Jan 95 10:53 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAA28656 for <HFSIG@tapr.org>; Tue, 3 Jan 1995 01:31:33 
-0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Tue, 3 Jan 95 8:51:21 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 3 Jan 95 8:51:02 PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Tue, 3 Jan 1995 08:50:59 PST8PDT 
Subject: HF Modulation 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <CAQCBBO55C2@frl.orst.edu> 
Hi All, 
Trust you had a good holiday season - best wishes for 1995. 


Apparently there were some problems with the listserver - hope it is 
working now. 


Bob asked an interesting question: whether soft decision decoding 

with convolutional coding was as effective as linear block coding 

with interleaving. There is an interesting, though rather oldish, paper 
about this that you may find interesting: 


"Effective Application of Forward-Acting Error-Control Coding to 
Multichannel HF Data Modems" by Pierce et. al. IEEE Trans. on COMM, 
Vol COM-18 (4), August 1970. pp 281-294. 


This paper compares early multi-tone parallel modems over HF paths and looks 
at how different phase and frequency shift modulation formats perform in 
conjunction with various linear block, as well as, convolutional codes. It 
appears that some block codes (i.e. (23,12)) code with interleaving does as 
well as a convolutional code with the appropiate constraint length (very 
large), however, it is not a simple matter to engineer the coding scheme 
without regard to the modulation scheme - these things should be engineered 
to work together and not separate. This comparison was by live 

experiments over transcontinental as well as transatlantic HF paths, and is 
about as old as the work done by Watterson on the HF channel simulator. 


I still am looking for further information on the Fast Hadamard Transform 
(or the Fast Walsh Transform). If anyone can shed some light on this, it 


would be greatly appreciated. 


73's 


Johan Forrer, KC7WW 


From k5yfw@k5yfw.ampr.org Tue Jan 03 20:50:35 1995 

Return-Path: <k5yfw@k5yfw.ampr.org> 

Received: from k5yfw.ampr.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrPLnV-O001N1C; Tue, 3 Jan 95 20:50 CST 

Date: Tue, 03 Jan 95 20:34:06 CST 

Message-Id: <2428@k5yfw.ampr.org> 

From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW) 

Reply-To: k5yfw@sat.n5lyt.ampr.org 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:170] HF modulation 

In-Reply-To: Your message of Thu, 29 Dec 94 21:34 CST 

X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS) 


Hi Gang, 


Wanna see video of a 53 year old ham sledding down a 1000 ft hill ona 
plastic sled? Wanna see the old feller go bump...wanna see the old 
feller's 2 1/2 year old granddaughter say "Owie Pappa?" Sun Valley 
(Ketchum?) will never be the same again. And no one answered my call on 
the 147.18 MHz Ketchem repeater. 


Boooooooo! 


In message <941226232538_70730.3472_CHK57-1@CompuServe.COM> Johan writes: 
[stuff deleted] 

> I also did capture the simulated output waveform and was quite concerned 

after inspecting the plot - the presence of large spikes of significant 

magnitude (in some cases, some 10-15 dB over the RMS value). This 

situation will certainly introduce data errors if not addressed. It should be 

stressed 

that such a signal will sound like a noise burst - it has little or no melody 

associated with 

it, except for the bit synchronizing pre-ambles. 


VV VV VV MV 


I heard a couple of Harris engineers talking about the problem 
once...I think they fixed it in there MIL-STD-188-110 modems 39 
tone modem. 


Boy does the signal ever sound like noise...as you tune across 
the signal the S meter will rise and fall and you will think you 
are just tuning a noisy frequency. 


You need a receiver capable of 10 Hz resolution to receive this 
modulation and if you're receiver (transceiver) dial/readout 
doesn't show 10 Hz steps, you will need to have a tuning 
indicator built into the software. 


It ix my opinion, that after this initial analysis, that such a scheme may be 
quite doable on our present hardware. I have no doubt that, if signal synthesis 
and fast 

Fourier transform are performed on the DSP side, there should be plenty of 
computing power in a modest PC to run the remainder of such a modem, even 
considering the computing demands for error coding. 


VV VV VV MV 


Sounds good to me. 


> Hope you all enjoyed the holiday season. Trust that 1995 will hold 
> the best in health peace for you. 


Yep, my holidays were fun fun fun. Spoiled my granddaughter 
again just to get back at my son. 


73 & CUL, 
Walt@home.2.nite 


From dlmill@mtu.edu Wed Jan 04 09:36:48 1995 
Return-Path: <dlmill@mtu.edu> 
Received: from mtu.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxPX1W-0000i4C; Wed, 4 Jan 95 09:36 CST 
Received: from [141.219.23.194] (techmaci1.tech.mtu.edu [141.219.23.194]) by 
mtu.edu (8.6.9/8.6.9) with SMTP id KAA15878 for <hfsig@tapr.org>; Wed, 4 Jan 1995 
10:36:37 -0500 
Message-Id: <199501041536.KAA15878@mtu.edu> 
X-Sender: dlmill@techsrv1.tech.mtu.edu 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Wed, 4 Jan 1995 10:36:17 -0500 
To: hfsig@tapr.org 
From: dlmill@mtu.edu (Dan Miller) 
Subject: subscribe 


Could someone please email me how to subscribe to this list? 
Dan dlmill@mtu.edu 


From shall@rain.org Wed Jan 04 11:09:49 1995 
Return-Path: <shall@rain.org> 
Received: from coyote.rain.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxPZDX-O000vxrC; Wed, 4 Jan 95 11:09 CST 
Received: by coyote.rain.org(4.1/SMI-RAIN) with id AA17694 
for hfsig@tapr.org on Wed, 4 Jan 95 09:05:58 PST 
Date: Wed, 4 Jan 1995 09:05:57 -0800 (PST) 
From: Stephen Hall <shall@rain.org> 
To: hfsig@tapr.org 
Cc: hfsig@tapr.org 
Subject: Re: [HFSIG:175] subscribe 
In-Reply-To: <199501041536.KAA15878@mtu.edu> 


Message-Id: <Pine.SUN.3.90.950104090343 .17248A-100000@coyote.rain.org> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


As I've forgotten, I too would like this posted. I have some friend that 
would like to subscribe additionally. 


On Wed, 4 Jan 1995, Dan Miller wrote: 


> Could someone please email me how to subscribe to this list? 

> Dan dlmill@mtu.edu 

> 

> 

> 

From FORRERJ@frl.orst.edu Wed Jan 04 11:14:58 1995 

Return-Path: <FORRERIJ@frl.orst.edu> 

Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrPZIM-O0000sSC; Wed, 4 Jan 95 11:14 CST 

Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 

(8.6.9/8.6.9) with SMTP id BAAO3199 for <hfsig@tapr.org>; Wed, 4 Jan 1995 01:53:36 

-0800 

Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Wed, 4 Jan 95 9:13:26 PST8PDT 

Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 4 Jan 95 9:13:24 PST8PDT 

From: "Johan Forrer 

FL" <FORRERJ@£rl.orst.edu> 

Organization: Forest Research Lab. Oregon State 

To: hfsig@tapr.org 


Date: Wed, 4 Jan 1995 09:13:17 PST8PDT 
Subject: Re: [HFSIG:176] Re: subscribe 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <CB92BCD39FA@frl.orst.edu> 
Hi, 


Hope this helps. 


Greetings from TAPR! 


TAPR can be reached via the Internet. The Automated Information Server that 
TAPR provides allows anyone to request information on TAPR, products, 
newsletters, and lots of other files. To find out more about this service, 
send an e-mail message to listserv@tapr.org with the subject line "Request" 
and the following text in the body of the message: 


help (for a brief set of instructions) 


index -all (for a list of all file by topic area) 
list (for a list of TAPR Mail Groups) 
get tapr taprinfo.txt (or info on TAPR) 


In the above message example, "help" retrieves a brief set of instructions 
for info, "index -all" retrieves a list of available files by topic and 
"“taprinfo.txt" retrieves a text file containing information on TAPR and what 
TAPR is all about. If you want to retrieve several text files with one 
message, use a separate line for each "get filename" request. 


General Information: 
* Ever heard of a TNC ? 
* Interested in general packet radio information? 
x Interested in high-speed packet operations? 
x Interested in other types of digital communications? 
x Interested in experimenting or building kits? 


x Interested in keeping up-to-date on national digital and packet 
issues? 


Then you might be interested in TAPR! 


Goals: 


*% Support Research and Development efforts in the area of 
amateur digital communications 


% Disseminate information on packet and digital communications 
% Provide affordable and useful kits for experimenters and hobbyists 
% Pursue and help advance the amateur art of communications through 
publications, meetings, and standards 
History: 


If you have used a packet radio TNC, then you are already a part of TAPR 
history. 


The TNC (Terminal Node Controller) project grew from a discussion in 
October of 1981 at a meeting of the Tucson Chapter of the IEEE Computer 
Society. A week later, six of the attendees gathered and discussed the 
feasibility of developing a Terminal Node Controller that would be complete 


and available to amateurs at a modest cost. This was the genesis of TAPR. 


On June 26th 1982, Lyle Johnson, WA7GXD, and Den Connors, KD2S, initiated 
a packet contact with the first TAPR unit. The project progressed from 
these first prototype units to the TNC-1 and then finally to the TNC-2 which 
is now the basis for most amateur packet operations worldwide. 


TAPR was founded in 1982 as a national organization with interests in the 
areas of packet and digital communications. Today, TAPR continues as a 
membership supported non-profit amateur research and development 
organization. TAPR currently has more than 2000 members, worldwide. TAPR 
continues to develop kits for the amateur community and is working actively 
on publications and communications standards. 


Membership: 


Membership in TAPR includes a subscription to the quarterly published 
Packet Status Register newsletter. PSR has been published since 1982 and is 
recognized as an authoritative source for up-to-date user and technical 
information on packet radio. Much of the material in PSR is timeless. Back 
issues may be obtained from the TAPR office. Membership in TAPR is $15 for 
one year. In Canada and Mexico membership is $18 and outside North America 
they are $25. 


Join the amateur digital-revolution -- Join TAPR! 
Special Interest Groups 
TAPR maintains several SIGs in various areas. To get the latest list of 
SIG groups, send an e-mail message to listserv@tapr.org with the subject 
line "Request" and the following text in the body of the message: 


list (for list of mail groups on TAPR.ORG) 


To request the information on any mail group, send an e-mail message to 
listserv@tapr.org and in the message text include: 


information listname (where listname is the name of the mail 
group) 


When you are ready to subscribe, send e-mail to listserv@tapr.org with the 
following command in the message text: 


subscribe <list> <your name> 


List should be the name of the mail list you want to join and Your Name 
should be both your First and Last Name. 


Current SIGs include: 


NETSIG Regional Networking SIG 


BBSSIG BBS SIG 
HFSIG SIG on HF Digital Topics 
DSP DSP Software Development Forum 
DSP-93 SIG for those that are building TAPR/AMSAT DSP-93 kits 
APRSSIG SIG on APRS 
FTP users 


The TAPR Software Library is now available via anonymous FTP. You can 
access the library by ftp access to 'ftp.hereford.ampr.org' in the directory 
pub/hamradio/tapr. Login in as 'anonymous', with a password of 
‘'your_account@internet_address'. 


Packet Raido and TAPR is on the World-Wide-Web! 


The series is accesible through the Packet Radio Home Page at this 
URL: 
http: //bb.iu.net/infomotion/taprhome. html 


http: //bb.iu.net/infomotion/pkthome. html 


What's here? A page of links (the Home Page), the TAPR Home Page, a page of 
Packet Pioneers and Contacts, a hypertext packet primer and FAQ, and more. 


Thanks to Howie, N2WX, President of Infomotion, for his support and 
invaluable 
contributions of the TAPR page. 


Tucson Amateur Packet Radio 

8987-309 E. Tanque Verde Road #337 

Tucson, AZ 85749-9399 

817-383-0000 (Tuesday - Friday 9:00-11:00am, 3:00-5:00pm CT) 
(15:00-17:00, 21:00-23:00 UTC) 

817-566-2544 FAX 


Internet: TAPR@TAPR.ORG 


From ericr@lan.vita.org Wed Jan 04 16:19:47 1995 
Return-Path: <ericr@vita.org> 
Received: from relay3.UU.NET by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrPe3U-O001GVC; Wed, 4 Jan 95 16:19 CST 
Received: from lan.vita.org by relay3.UU.NET with SMTP 
id QQxxgz18265; Wed, 4 Jan 1995 17:19:35 -0500 
Received: by lan.vita.org (5.64/PERFORMIX-0.9/08-16-92) 
id AA14653; Wed, 4 Jan 95 16:49:57 EST 


Date: Wed, 4 Jan 1995 16:49:57 -0500 (EST) 

From: Eric Rosenberg <ericr@lan.vita.org> 

Subject: System Design In Africa 

To: hfsig@tapr.org 

Message-Id: <Pine.3.89.9501041620.B14644-0100000@lan.vita.org> 
Mime-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


VITA, Volunteers in Technical Assistance, a non-profit development 
organization based in Arlington, VA is looking for a qualified volunteer 
consultant to design a terrestrial digital radio network in Guinea, west 
Africa. 


VITA presently operates nine offices in Guinea, most of which are already 
connected by a voice (radio) network. 


The consultant will meet with the project staff at the Country Office in 
Conakry to determine their needs and requirements, and then travel to 
some (or all) of the field offices to perform a first-hand site survey. 


Upon returning home, the consultant will provide VITA with a written 
report outlining the system needs with respect to hardware and software, 
detail the network architecture, and make recommendations on equipment 
and software to be installed at a future date. This is *xnot*x an amateur 
radio network. Familiarity with amateur radio among the project staff in 
Guinea is, at best, slight. 


The trip will last two weeks, and will begin in late January or early 
February. VITA will be responsible for all costs and expenses related to 
this trip, but is not in a position to pay a professional fee. 


The consultant must have experience in the following areas: HF voice and 
digital communications; system and network design; familiarity with existing 
hardware and software; working knowledge of French; 


If you are interested or require additional information, please contact 
Eric Rosenberg at the e-mail address below. 


Eric Rosenberg 

Volunteers In Technical Assistance voice: +703-276-1800 
1600 Wilson Blvd., Suite 500 fax: +703-243-1865 
Arlington, VA 22209 USA ericr@vita.org 


From gjones@tenet.edu Wed Jan 04 18:51:34 1995 

Return-Path: <gjones@tenet.edu> 

Received: from Leslie-Francis.tenet.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrPgQ0-O0000xYC; Wed, 4 Jan 95 18:51 CST 

Received: (from gjones@localhost) by Leslie-Francis.tenet.edu (8.6.9/8.6.9) id 

SAA00858 for hfsig@tapr.org; Wed, 4 Jan 1995 18:51:32 -0600 


From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199501050051.SAA00858@Leslie-Francis.tenet.edu> 

Subject: Re: [HFSIG:176] Re: subscribe 

To: hfsig@tapr.org 

Date: Wed, 4 Jan 1995 18:51:31 -0600 (CST) 

In-Reply-To: <Pine.SUN.3.90.950104090343 .17248A-100000@coyote.rain.org> from 
"Stephen Hall" at Jan 4, 95 11:11:00 am 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 397 


Send email to listserv@tapr.org 
in the message, say 

get tapr taprinfo.txt 

Cheers - Greg 


According to Stephen Hall: 


> 

> As I've forgotten, I too would like this posted. I have some friend that 
> would like to subscribe additionally. 

> 

> 

> 

> On Wed, 4 Jan 1995, Dan Miller wrote: 

> 

> > Could someone please email me how to subscribe to this list? 
> > Dan dlmill@mtu.edu 

2 > 

>> 

>> 

> 


From karn@qualcomm.com Wed Jan 04 20:57:14 1995 

Return-Path: <karn@qualcomm. com> 

Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrPi00-00010dC; Wed, 4 Jan 95 20:57 CST 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id SAA11090; 

Wed, 4 Jan 1995 18:29:09 -0800 

Date: Wed, 4 Jan 1995 18:29:09 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199501050229.SAA11090@servo.qualcomm. com> 

To: FORRERJ@fxr1.orst.edu 

CC: hfsig@tapr.org 

In-reply-to: <B80FA331EF6@frl.orst.edu> (FORRERJ@fr1l.orst.edu) 

Subject: Re: [HFSIG:163] Re: Ideas for HF modulation and coding 


>1) (ODFM) n-parallel carriers with orthoganal signaling. All carriers 

>are always present. Demodulation is performed by FFT's. It is obvious that 
>the choice of the FFT size and sample rate have to just right otherwise we 
>will end up with an odd distribution of our carriers over the 


>frequency/phase bins. After this choice have been made, how do I use this 
>I/Q recovered data? I have some wild ideas, but would like to obtain 
>further input first. 


Nothing says you have to demod this with an FFT, although that's one 
way to do it. Once you determine carrier phase and symbol timing, you 
just generate a bunch of local carrier references, multiply each by 
the received signals, and integrate and dump or however you want to 

do the matched filtering. Of course, if you pick the right numbers you 
would make it easier to do this with an FFT. 


>2) (Phil's method based on Welch functions) n-parallel tones with orthoganal 
>signaling. Only a small subset of carriers are present at a time - the 
>different subset is selected from a Hamadard matrix. In a sense, 


Actually, except for one codeword of all zeros the orthogonal 
functions all have 50% of their bits on and 50% off. 


>Piccolo may be considered a special case of this idea, where only one 
>carrier is sent at a time from a set of m-carriers. Phil mentioned that FHT 
>(is that for fast hadamard transform?) is used to perform demodulation. How 
>about telling us a bit more about how to implement this one Phil. 


As I understand it, piccolo only sends one tone at a time. What I've 
proposed is the same thing except for an additional layer of 
orthogonal signalling in the form of the walsh functions on top of the 
orthogonal tone set. This is the layer you'd decode with the FHT. 


Whether or not this extra layer helps in a real HF channel is unknown. 


Phil 


From karn@qualcomm.com Wed Jan 04 22:55:55 1995 

Return-Path: <karn@qualcomm. com> 

Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxPkEs-000111C; Wed, 4 Jan 95 22:55 CST 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id UAA11138; 

Wed, 4 Jan 1995 20:57:48 -0800 

Date: Wed, 4 Jan 1995 20:57:48 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199501050457 .UAA11138@servo.qualcomm. com> 

To: k5yfw@sacdm10.kelly.af.mil 

CC: hfsig@tapr.org 

In-reply-to: <mOrKrSm-Q002ANC@sacdm10.kelly.af.mil> (k5yfw@sacdm10.kelly.a£.mil) 

Subject: Re: [HFSIG:165] Re: HF Modulation Modes 


Do we want to design a modem for the worse-case scenario or 
can we live with one that can get data thru on the worst 
channel part of the time. I have a pick-up without 4 wheel 
drive...there are at times places I can't drive...so I don't 
drive there until conditions are better. There are places 
where I can drive without 4 wheel drive that my Geo Metro can 


VV VV VV 


> never go. Should I have 4 wheel drive? Do we need a modem 
that can get thru even the worst conditions or can we settle 
> for something less. Are we purist or realists? 


Vv 


The newer telephone modems are highly adaptive to line quality. Perhaps 
xtoox adaptive. Lots of different baud rates, symbol constellations 

and coding rates. It helps, but it sure does complicate things if you're 
not careful. 


Phil 

From karn@unix.ka9q.ampr.org Thu Jan 05 04:47:02 1995 

Return-Path: <karn@unix.ka9q.ampr.org> 

Received: from unix.ka9q.ampr.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrPpic-00004zC; Thu, 5 Jan 95 04:46 CST 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id CAAQ8743; Thu, 5 

Jan 1995 02:49:40 -0800 

Date: Thu, 5 Jan 1995 02:49:40 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199501051049.CAAQ8743@unix.ka9q.ampr.org> 

To: jmorriso@bogomips.ee.ubc.c 

CC: hfsig@tapr.org 

In-reply-to: <mOrLExU-0004giC@bogomips.ee.ubc.ca> (jmorriso@bogomips.ee.ubc.ca) 

Subject: Re: [HFSIG:169] Re: HF Modulation Modes 


>This isn't related to HF, but: would some modulation like Piccolo (I 
>think I missed the description for that) be applicable to sending a 
>data stream over a 2m or 7Ocm narrow-band FM voice radio? And 
>preferably through a voice repeater as well. Speed would be about 50 
>bps or so, just enough to send your callsign or a very short message 
>when you key up the radio. 


Not really. The key to your question is the phrase "narrow-band". Piccolo, 
and other m-ary orthogonal schemes, are specifically designed to spend 
bandwidth in order to save on required S/N ratio. 


Automatic transmitter IDing is already quite easily done with conventional 
binary modems. I think MSK is fairly popular for this purpose on public 
service radios. At least you hear it all the time on cop shows. 


Phil 

From esilbaug@afit.af.mil Sat Jan 07 12:10:27 1995 

Return-Path: <esilbaug@afit.af.mil> 

Received: from stealth.afit.af.mil by dptspd.sat.datapoint.com with smtp 

(Smail3.1.29.1 #5) id mOrQfap-O0000QdC; Sat, 7 Jan 95 12:10 CST 

Received: from eagle.afit.af.mil by stealth.afit.af.mil with SMTP id AA08932 
(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Sat, 7 Jan 1995 13:10:19 -0500 

Date: Sat, 7 Jan 1995 13:10:19 -0500 

From: Eric E Silbaugh <esilbaug@afit.af.mil> 

Message-Id: <199501071810.AA08932@stealth.afit.af.mil> 

To: hfsig@tapr.org 

Subject: Re: HF modulation 

Cc: esilbaug@afit.af.mil 


I have been following the discussion on OFDM and studying 
Phil's intriguing proposal for using M-ary orthogonal FSK 
with Walsh functions. Over Christmas break (I'm pursuing 
an MSEE; if only I could catch it) I did some crude 
simulations of Phil's scheme using MATLAB. 


First, I generated a 64x64 Hadamard matrix (whose rows are 
Walsh functions). Then I generated 64 equal amplitude 
sinusoids, each separated by 32 Hz, from 512 Hz to 2528 Hz. 
I then picked a row at random from the Hadamard matrix to 
determine which sinusoids to sum together. I sampled the 
time sequence at 32 kHz and plotted it over a full period 
of the combined signal. 


I used several different Walsh functions to get a feel for 
the general behavior of these signals. Since I started with 
64 tones, and only 1/2 are on for any particular Walsh 
function, I was combining 32 separate tones. The results 
were rather interesting, and very similar to Johan's. 


Thus wrote Johan, KC7WW: 


As a way to learn more about how OFDM works for the 
39-tone MIL-STD-188 parallel modem, I wrote a C program 
that simulates 39 parallel tones and combines them into 
a single output signal. 


VV VV 


[snip] 


I also did capture the simulated output waveform and was 
quite concerned after inspecting the plot - the 
presence of large spikes of significant magnitude (in 
some cases, some 10-15 dB over the RMS value). 


VVV WV 


My simulation produced signals with peak-to-RMS ratios of 

9 dB, they were generally of low amplitude except where 

the sinusoids came into phase and produced a large peak, 
and they generally looked 'noiselike'. I also noticed that 
the signal's peak amplitude was not symetric about the time 
axis. The signals had zero average value but the largest 
positive-going peak was twice as high as the largest 
negative-going peak. 


As several others have noted, this high peak-to-RMS ratio 
will limit the amount of energy per symbol. A signal such 
as this is potential trouble in any amplifier unless care is 
taken to control the peak level. The asymetry in peak 
heights may furthur limit the amount of power an amplifier 
could deliver. This is definitely not a constant envelope 
signal so linear amplifiers are in order. As more tones are 
added the signals will have larger peak-to-RMS ratios. This 
is consistent with Johan's observations since he was summing 


more tones. 


The FCC limits amateurs based on PEAK envelope power (PEP), 
not RMS power. As Phil noted, coding gains can buy back 
most of the loss in energy per symbol caused by the low RMS 
value of the signal, but it's still a significant limitation. 
Disregarding interference, it's ultimately the energy per 
bit that determines the performance of a digital system. 


Phil's proposal was for a noncoherent system, which got me 
thinking (scary, eh?). A noncoherent system ignores the 
phase of a signal; so, we have a free parameter to play with. 
My initial simulation started each sinusoid at zero phase. 

If we could use the phase to reduce the peak value of the 
signal we could get more energy per symbol and get the coding 
gain as well. 


First I tried a linear shift in the initial phase across all 
64 sinusoids. I started with zero initial phase at the lowest 
frequency and increased the phase linearly to two pi at the 
highest frequency. This resulted in signals with about the 
same peak-to-RMS ratios (8.25 dB), still 'noiselike', but the 
amplitude peaks became symetrical about the time axis 
(interesting and unexpected). 


My next attempt was to assign a random initial phase to 

each of the 64 sinusoids. The initial phase was distributed 
uniformly between zero and two pi. This produced signals with 
an average peak-to-RMS ratio of 4.75 dB, the signals looked 
extremely 'noiselike', and the amplitude peaks were nearly 
symetrical. Progress! 


These were just the first ways I thought of to change the 
phase, there was no method to my maddness. Even a naive 
method like ramdomizing the phase produced a 4 dB reduction 
in the peak-to-RMS ratio. These results lead to a conjecture 
and several questions. 


My conjecture is that we can reduce the peak-to-RMS ratio 
further, and maybe even approximate a constant envelope 
signal, by properly choosing the phases of the sinusoids. 
I think this is plausible since a wideband FM signal is a 
constant envelope signal and its spectrum looks like a set 
of nearly equal amplitude sinusoids, within a limited 
bandwidth. I doubt we could get a truly constant envelope 
signal because we are using a small set of harmonically 
related sinusoids. 


Some questions I have: 
- Are there systematic methods for choosing the 


initial phases of the sinusoids to minimize the 
peak-to-RMS ratio? 


- What limits are there on reducing the peak-to-RMS 
ratio? 


- Are these limits, if they exist, related to the 
number of sinusoids or the Walsh function used? 


- Is this a well-known (or obscure) problem that 
already has a solution? 


- Is reducing the peak-to-RMS ratio really as 
important as I seem to think it is? 


The MIL-STD modems apparently use PSK on the tones as well. 
Since the phase of any particular sinusoid in my simulation 
was constant over the symbol period this should allow using 
methods such as DPSK on the tones if someone wants to add an 
additional layer of modulation. Would this increase the 
peak-to-RMS ratio? 


I can provide the MATLAB M-files I used for this simulation 
if anyone is interested in duplicating, or extending, my 
results. Thoughts anyone? 


Eric, N2NNP 


ae a as Eric E. Silbaugh 
; eee esilbaug@afit.af.mil 


Hae All standard, non-standard, and 
Se Si ees Sethe ate, Soc hae MIL-STD disclaimers apply 


From larry@owrlakh.unbc.edu Sat Jan 07 16:05:10 1995 

Return-Path: <larry@owrlakh.unbc.edu> 

Received: from owrlakh.unbc.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrQjFw-OQO0OhUC; Sat, 7 Jan 95 16:05 CST 

Received: (from larry@localhost) by owrlakh.unbc.edu (8.6.9/8.6.9) id OAA02948 for 

hfsig@tapr.org; Sat, 7 Jan 1995 14:04:57 -0800 

From: Larry Gadallah <larry@owrlakh.unbc.edu> 

Message-Id: <199501072204 .OAAQ2948@owrlakh.unbc.edu> 

Subject: Re: [HFSIG:183] 

To: hfsig@tapr.org 

Date: Sat, 7 Jan 1995 14:04:56 -0800 (PST) 

In-Reply-To: <mOrQfgn-0000Coa@dptspd.sat.datapoint.com> from "hfsig@tapr.org" at 

Jan 7, 95 12:16:00 pm 

X-Mailer: ELM [version 2.4 PL23] 

MIME-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 

Content-Length: 1175 


Eric E Silbaugh <esilbaug@afit.af.mil> writes: 


I have been following the discussion on OFDM and studying 
Phil's intriguing proposal for using M-ary orthogonal FSK 
with Walsh functions. Over Christmas break (I'm pursuing 
an MSEE; if only I could catch it) I did some crude 
simulations of Phil's scheme using MATLAB. 


First, I generated a 64x64 Hadamard matrix (whose rows are 
Walsh functions). Then I generated 64 equal amplitude 
sinusoids, each separated by 32 Hz, from 512 Hz to 2528 Hz. 
I then picked a row at random from the Hadamard matrix to 
determine which sinusoids to sum together. I sampled the 
time sequence at 32 kHz and plotted it over a full period 
of the combined signal. 


VV VV VV VV VV VV VV 


> 
Can anyone provide a good reference to what some of these 
things are (i.e. Walsh functions, Hadamard matrices)? 


Thanks and 73, 


Larry Gadallah Prince George, BC 
Internet: larry@owrlakh.unbc.edu TPC: (604) 964-1140 
VEATCP/VE6VQ ICBM: 53:51'38.4"N 122:44'25.8"W 


From k5yfw@sacdm10.kelly.af.mil Mon Jan 09 08:31:36 1995 
Return-Path: <k5yfw@sacdm10.kelly.af£.mil> 
Received: from sacdm10.kelly.af.mil by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxRL8A-OQOOObPC; Mon, 9 Jan 95 08:31 CST 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOrRL3U-0002CeC; Mon, 9 Jan 95 08:26 CST 
Message-Id: <mOxRL3U-0002CeC@sacdm10.kelly.af.mil> 
Date: Mon, 9 Jan 95 08:26:43 -0600 
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 
Subject: G-TOR Goes Public 
To: hfsig@tapr.org 
Reply-to: k5yfw@sat.ampr.org 


G-TOR Goes Public 
by Walt DuBose, K5YFW 
While at the local "ham store" on Christmas Eve, my XYL WB5WXY, 
suggested that I buy a "ham book" (she meant magazine I'm sure) to 


read while we were flying to Idaho Christmas day. 


While looking at the various "books", I spotted "G-TOR, The New Mode". 
My wife was a little surprised at the $16 price but I assured here 


this would keep me occupied and it has. 


The cover says "Articles, Charts, Protocol". Copyright by Kantronics, 
this 90 page book is crammed with articles and papers on G-TOR. While 
many articles are redundant, reading several articles will give you a 
good working knowledge of G-TOR and why Kantronics is proud of their 
product. 


Not only is the book filled with articles, it also contains charts 
and a complete description of the protocol. 


I will have to re-read several articles to ensure that I fully 
understand this protocol. For those with programming background, I 
feel confident that they will get much more out of this book that a 
non-technical person like me. 


While not everyone will want to rush out and purchase this book, 
those truly interested in high speed HF data communications will 
want a copy. This is also an excellent reference for your radio 
club's library. 
From k5yfw@sacdm10.kelly.af.mil Mon Jan 09 10:25:26 1995 
Return-Path: <k5yfw@sacdm10.kelly.af.mil> 
Received: from sacdm10.kelly.af.mil by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxRMUuH-O000f2C; Mon, 9 Jan 95 10:25 CST 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOrRMpu-0001z£C; Mon, 9 Jan 95 10:20 CST 
Message-Id: <mOxrRMpu-0001zfC@sacdm10.kelly.af.mil> 
Date: Mon, 9 Jan 95 10:20:49 -0600 
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 
Subject: Re: G-TOR Booklet 
To: rs@ife.ee.ethz.ch 
Cc: hfsig@tapr.org 
X-orig-date: Mon, 9 Jan 95 16:13:55 MET 
X-orig-from: Rolf Sommerhalder <rs@ife.ee.ethz.ch> 
X-orig-message-ID: <9501091513 .AAQ05551@ife> 


I'm sorry, I guess I should have included the information. The title 
of the book is "G-TOR, The New Mode", copyright and published by: 


Kantronics Company, Inc 

1202 E. 23rd St. 

Lawrence, KS 66046 

U.S. Telephone Number: 913/842-7745 


I believe you can only get it from Kantronics or through one of their 
equipment distributors. 


73: 


Walt 


In your message of 9 Jan 1995 at 1613 CST, you write: 
> Hi Walt 
> 
> Thanks for your very interesting hint. 
> Could you please give us (overseas) more info about publisher/publishing date 
and place 
> and so on, so that we can order it by a local book-store. 
> Maybe this booklet even has an international book number (in the form of 
ISSN-...) or 
> maybe there is an indication/address/fax-number where we could purchase it ? 
> 
> (I am probably not going to implement that protocol on my DSP (as I did with 
PACTOR), but 

would also enjoy the reading about the algorithms behind). 


Thanks for your help es vy 73s, 
Rolf 


ee a a 


Swiss Federal Institute of Technology (ETH) home address: 
Electronics Laboratory ETZ H60.1 c/o Rindlisbacher 
Gloriastrasse 35 Wermatswilerstrasse 96 
8092 Zurich / Switzerland 8610 Uster / Switzerland 


> 
> 
> 
> 
> 
> 
> 
> Rolf Sommerhalder 
> 
> 
> 
> 
> 
> Voice +41 1 632 76 40 (or 632 51 53) Voice +41 1 941 59 28 
> Fax +41 1 632 12 10 AX.25 HB9CWP @ HB90S 
> E-Mail rolf.sommerhalder@ife.ee.ethz.ch Swiss Disaster Relief HBK81 
> 
From shall@rain.org Mon Jan 09 11:03:05 1995 
Return-Path: <shall@rain.org> 
Received: from coyote.rain.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxRNUm-OQOOOT9C; Mon, 9 Jan 95 11:03 CST 
Received: by coyote.rain.org(4.1/SMI-RAIN) with id AAQ1767 
for hfsig@tapr.org on Mon, 9 Jan 95 08:59:12 PST 
Date: Mon, 9 Jan 1995 08:59:11 -0800 (PST) 
From: Stephen Hall <shall@rain.org> 
To: hfsig@tapr.org 
Cc: Ross duClair <CPTRoss@aol.com> 
Subject: Re: [HFSIG:186] Re: G-TOR Booklet 
In-Reply-To: <mOrRMpu-0001z£C@sacdm10.kelly.af.mil> 
Message-Id: <Pine.SUN.3.90.950109085422 .1092A-100000@coyote.rain.org> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Rolf, Regarding G-TOR: I attended a talk given by Phil Anderson regarding 
G-TOR vs. Pactor and it appeared that G-TOR has much more powerful error 
correction than Pactor. I would be interested in your evaluation after 
you have had an opportunity to check it out. Steve, WM6P 


On Mon, 9 Jan 1995, WALT DUBOSE - K5YFW wrote: 


I 


I 


> 
> 
> 
> 
and 


VV VV VV VV VV VV VV VV VV VV VV 


'm sorry, I guess I should have included the information. The title 
of the book is "G-TOR, The New Mode", copyright and published by: 


Kantronics Company, Inc 

1202 E. 23rd St. 

Lawrence, KS 66046 

U.S. Telephone Number: 913/842-7745 


believe you can only get it from Kantronics or through one of their 


equipment distributors. 
73, 


Walt 


In your message of 9 Jan 1995 at 1613 CST, you write: 


Hi Walt 


Thanks for your very interesting hint. 
Could you please give us (overseas) more info about publisher/publishing date 
place 


> > and so on, so that we can order it by a local book-store. 

> > Maybe this booklet even has an international book number (in the form of 
ISSN-...) or 

> > maybe there is an indication/address/fax-number where we could purchase it ? 
>> 

> > (I am probably not going to implement that protocol on my DSP (as I did with 


PACTOR), but 


> 


VV VV VV VV VV VV VV VV VOM 
VV VV VV VV VV VV VV VV 


would also enjoy the reading about the algorithms behind). 


Thanks for your help es vy 73s, 
Rolf 


ne a a 


Rolf Sommerhalder 

Swiss Federal Institute of Technology (ETH) home address: 
Electronics Laboratory ETZ H60.1 c/o Rindlisbacher 
Gloriastrasse 35 Wermatswilerstrasse 96 
8092 Zurich / Switzerland 8610 Uster / Switzerland 


Voice +41 1 632 76 40 (or 632 51 53) Voice +41 1 941 59 28 
Fax +41 1 632 12 10 AX.25 HB9CWP @ HB90S 
E-Mail rolf.sommerhalder@ife.ee.ethz.ch Swiss Disaster Relief HBK81 


From BLOOM_ALAN/HP5300_RO@opnmail3.corp.hp.com Mon Jan 09 13:27:35 1995 
Return-Path: <BLOOM_ALAN/HP5300_RO@opnmail3.corp.hp.com> 
Received: from hp.com by dptspd.sat.datapoint.com with smtp 


(Smail3.1.29.1 #5) id mOrRPka-00013TC; Mon, 9 Jan 95 13:27 CST 
Received: from opnmail3.corp.hp.com by hp.com with SMTP 
(1.37.109.14/15.5+ECS 3.3) id AAQ74039647; Mon, 9 Jan 1995 11:27:27 -0800 
Received: from by opnmail3.corp.hp.com with SMTP 
(1.37.109.8/15.5+ECS 3.3) id AA25081; Mon, 9 Jan 1995 11:27:26 -0800 
From: BLOOM_ALAN/HP5300_RO@opnmail3.corp.hp.com 
X-Openmail-Hops: 2 
Date: Mon, 9 Jan 95 11:11:00 -0800 
Message-Id: <d0ey1SyO0Q0000000@MHS> 
Subject: Re: HF modulation 
To: hfsig@tapr.org 


Eric Silbaugh wrote: 
(Re: OFDM) 


>My simulation produced signals with peak-to-RMS ratios of 
>9 dB, 


>As several others have noted, this high peak-to-RMS ratio 
>will limit the amount of energy per symbol. 


>The FCC limits amateurs based on PEAK envelope power (PEP), 
>not RMS power. As Phil noted, coding gains can buy back 
>most of the loss in energy per symbol caused by the low RMS 
>value of the signal, but it's still a significant limitation. 
>Disregarding interference, it's ultimately the energy per 
>bit that determines the performance of a digital system. 


Of course, lower average power also means less interference to 
other users. Since the signal will be spread over several kHz, 
the energy per 300 Hz channel will be low. Interference xfromx 
other users (analog or digital) can be reduced with proper coding. 


>A noncoherent system ignores the 

>phase of a signal; so, we have a free parameter to play with. 
>My initial simulation started each sinusoid at zero phase. 
>If we could use the phase to reduce the peak value of the 
>signal we could get more energy per symbol and get the coding 
>gain as well. 


>My next attempt was to assign a random initial phase to 

>each of the 64 sinusoids. The initial phase was distributed 
>uniformly between zero and two pi. This produced signals with 
>an average peak-to-RMS ratio of 4.75 dB, the signals looked 
>extremely 'noiselike', and the amplitude peaks were nearly 
>symetrical. Progress! 


>These were just the first ways I thought of to change the 
>phase, there was no method to my maddness. Even a naive 
>method like ramdomizing the phase produced a 4 dB reduction 
>in the peak-to-RMS ratio. 


The "naive method" may be pretty close to optimal. Since the 
number of cycles per symbol of each carrier differs from each 
of the others by an integer number of cycles, each pair of 
carriers will be in phase (3 dB peak-to-average) sometime 
during each symbol. Intuitively, it seems like you could 
never do that well with many carriers. 


Al Bloom N1AL 
From FORRERJ@frl.orst.edu Mon Jan 09 13:59:56 1995 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrRQFq-O0000zZFC; Mon, 9 Jan 95 13:59 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id EAA24359 for <hfsig@tapr.org>; Mon, 9 Jan 1995 04:37:54 
-0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Mon, 9 Jan 95 11:57:57 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 9 Jan 95 11:57:54 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 9 Jan 1995 11:57:49 PST8PDT 
Subject: Re: [HFSIG:188] Re: HF modulation 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <D33ED2758A7@frl.orst.edu> 
Eric E. Silbaugh wrote: 


>I have been following the discussion on OFDM and studying 
>Phil's intriguing proposal for using M-ary orthogonal FSK 
>ith Walsh functions. Over Christmas break (I'm pursuing 
>an MSEE; if only I could catch it) I did some crude 
>simulations of Phil's scheme using MATLAB. 


>First, I generated a 64x64 Hadamard matrix (whose rows are 
>Walsh functions). Then I generated 64 equal amplitude 
>sinusoids, each separated by 32 Hz, from 512 Hz to 2528 Hz. 
>I then picked a row at random from the Hadamard matrix to 
>determine which sinusoids to sum together. I sampled the 
>time sequence at 32 kHz and plotted it over a full period 
>of the combined signal. 


GAS e snip..... 
> - Are there systematic methods for choosing the 
> initial phases of the sinusoids to minimize the 
> peak-to-RMS ratio? 


Eric, just a suggestion: you may want to look at an earlier (way back) 


message thread on this very topic. It is recorded in an archive on ftp.ucsd 
in the DSP directory. If you have a problem obtaining it, I'll dig out the 
name of the archive. 


I think there is no good news here. There is no easy solution as far as 
I can gather (?). CLOVER, as an example, addressed this problem by using 
time and frequency interleaved signaling as well as pulse shaping. 


>The MIL-STD modems apparently use PSK on the tones as well. 
>Since the phase of any particular sinusoid in my simulation 
>was constant over the symbol period this should allow using 
>methods such as DPSK on the tones if someone wants to add an 
>additional layer of modulation. Would this increase the 
>peak-to-RMS ratio? 


I suspect it depends on the peak of the individual channel waveform. 


>I can provide the MATLAB M-files I used for this simulation 
>if anyone is interested in duplicating, or extending, my 
>results. Thoughts anyone? 


I, for one, am quite interested in your work, Eric. Likewise, if 
anyone is interested in the OFDM simulation, I would be happy to share 
the "C" source code. 


A bit of progress over the last weekend: I finished a FFT-based display 
scope program for the DSP sound card. Since I am interested in using the 
FFT-approach for doing an OFDM modem, thought that I could use the same 
FFT for different purposes. It's a 256-point radix-4 that includes 

a Hanning window (and log transform for calculations in dB, if needed) and 
does it in approximately 250 micro seconds. The first thing I did was to 
look at the audio frequency responses of my ICOM 751 - boy! was I 
surprised. 


I went ahead and played with the DSP sound card and implemented the parallel 
tone modulator and FFT-based OFDM demodulator - it is surprising to see 

how sensitive the FFT is to any clipping effects of these large spikes in 
the signal. One has to be real careful of this, else a bit of garbage seem 
to appear in the wrong frequency bins. However, when this kind of garbage 
ends up in the wrong frequency bin, it seems to appear as uncorrelated 

noise - the actual signal in the frequency bin still appears quite distinct 
and recoverable. Perhaps this side-effect is not all that serious 

after all. Comments? 


73's 


Johan, KC7WW 

From jojo@asti.dost.gov.ph Tue Jan 10 05:01:14 1995 

Return-Path: <jojo@asti.dost.gov.ph> 

Received: from christine.asti.dost.gov.ph by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxRdkv-OOOOMrC; Tue, 10 Jan 95 04:24 CST 

Received: from pia.dost.gov.ph (pia.asti.dost.gov.ph [165.220.44.53]) by 

christine.asti.dost.gov.ph (8.6.9/8.6.9) with SMTP id RAAQ4238; Tue, 10 Jan 1995 

17:59:20 +0800 

Date: Tue, 10 Jan 1995 17:59:20 +0800 

From: "Victorio 0. Ochave" <jojo@asti.dost.gov.ph> 

Message-Id: <199501100959.RAAOQ4238@christine.asti.dost.gov.ph> 

To: hfsig@tapr.org 

Subject: HF DSPs 

Cc: jojo@christine.asti.dost.gov.ph 


I'm a new member of the list, and also new in data comm over HF. We will be 
establishing some HF links here in the Philippines using GTOR. I was told that 
there are DSP filter units (Timewave DSP 59+) useful for PACTOR and AMTOR links. I 
was wondering if the same DSP units can make a substantial improvement in 
performance when using the GTOR protocol. 


All commentaries and advise on this will be highly appreciated. 


Victorio A. Ochave, Jr. 

Communications Engineering Division 

Advanced Science and Technology Institute (ASTI) 
Department of Science and Technology (DOST) 

4/F NEC Bldg., University of the Philippines 
Diliman, Quezon City, PHILIPPINES 1101 


voice: 632 995071-9 loc.5106 
fax: 632 9224714 
Internet: jojo@asti.dost.gov.ph 
ochave@itu.ch 
v.ochave@ieee. org 
X.400: G=victorio; S=ochave; P=itu; A=arcom; C=ch 


From Rick_Whiting@ATK.COM Tue Jan 10 10:35:51 1995 
Return-Path: <Rick_Whiting@ATK.COM> 
Received: from ATK.COM by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrRjXq-QO0000JC; Tue, 10 Jan 95 10:35 CST 
Received: from gateway1 by ATK.COM (8.6.9/8.6.9) 
id KAA18813; Tue, 10 Jan 1995 10:34:37 -0600 
Message-Id: <199501101634.KAA18813@ATK.COM> 
Date: 10 Jan 1995 10:39:11 -0600 
From: "Rick Whiting" <Rick_Whiting@ATK.COM> 
Subject: Re: [HFSIG-190] HF DSPs 
To: hfsig@tapr.org 


Reply to: RE>[HFSIG:190] HF DSPs 
Date: 1/10/95 5:14 AM 
To: Rick Whiting 
From: hfsig@tapr.org 
Victorio A. Ochave, Jr. <jojo@asti.dost.gov.ph> wrote: 


>I'm a new member of the list, and also new in data comm over HF. We >will be 
establishing some HF links here in the Philippines using GTOR. I >was told 
that there are DSP filter units (Timewave DSP 59+) useful for >PACTOR and 
AMTOR links. I was wondering if the same DSP units can >make a substantial 
improvement in performance when using the GTOR >protocol. 


>All commentaries and advise on this will be highly appreciated. 


Victorio, If the AF DSP filter helps for PACTOR and AMTOR it will similarly 
help for G-TOR. However, it is highly desired to develop the selectivity as 
high up in the receiver's IF as practical, rather than at AF. If the IF 
filters are too wide relative to the desired signal bandwidth, noise and 
interference outside the AF passband will still impact the radio, e.g., the 
AGC, and degrade reception even though you don't "hear" it out of the AF 
(DSP) filter. 


Unfortunately, many folks are trapped into using the too-wide filters that 
are supplied with their transceivers for HF data modes like PACTOR and G-TOR. 
And since the filters were not designed for data with respect to phase 
linearity, especially at the edges, the stock filters with about the "right" 
bandwidth may not work well either! Thus, in many practical applications the 
DSP filter at AF significantly improves performance. 


By the way, I think the Timewave DSP filters are top notch. 


73/Rick WOTN 


From karn@qualcomm.com Tue Jan 10 19:57:45 1995 

Return-Path: <karn@qualcomm. com> 

Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxRsJY-0001U1C; Tue, 10 Jan 95 19:57 CST 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id RAA25908; 

Tue, 10 Jan 1995 17:59:18 -0800 

Date: Tue, 10 Jan 1995 17:59:18 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199501110159.RAA25908@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <CAOCBBO55C2@frl.orst.edu> (FORRERJ@fr1.orst.edu) 

Subject: Re: [HFSIG:173] HF Modulation 


Johan says: 


>Bob asked an interesting question: whether soft decision decoding 
>with convolutional coding was as effective as linear block coding 
>with interleaving. 


I'd been meaning to comment on this, glad you reminded me. 


I've learned that this has been a rather controversial subject that 
some people argue with a fervor that approaches the classic VC vs 
datagram wars of 10 years ago. 


Up front I should say that I happen to work for one of the main 
parties to this debate (Andrew Viterbi) so my comments may be biased. 


Convolutional coding has the following general advantages: 
1. Better performance for equivalent code complexity 


2. Can use "soft decision" information for improved performance 
(2dB on AWGN) much more easily 


3. More easily adapted to arbitrary block sizes 


Block codes, as typified by Reed Solomon codes, have the following 
general advantages: 


1. No performance penalty for "systematic" codes (where the data 
appears unchanged as a subset of the coded output) 


2. Complex codes more easily implemented (partially negating 
convolutional advantage #1) 


3. No need to "tail off" blocks for full coding gain 
4. Less sensitive to burst errors 


5. Direct adaptability to higher-order modulation symbol alphabets, 
such as the m-ary FSK schemes I've been discussing. 


Nobody really disputes the correctness of any of these points, since 
they're amenable to mathematical proof. The arguments all center over 
the relevance of their assumptions, and which advantages are more 
important in practice. For example, both Viterbi and Reed-Solomon 
decoders are amenable to VLSI implementation, but differences in the 
details can give one a temporary advantage over the other. 


It's also common to combine convolutional and block codes to get the 
best of both worlds. These "concatenated" coding systems are commonly 
used in deep space communications, starting with Voyager. You run 

a Reed-Solomon block code on top of a Viterbi-decoded convolutional 
code, usually with an interleaver between the two. 


The Viterbi decoder does most of the work, and since it's directly 


connected to the modem it can benefit from soft decision samples. But 
when the Viterbi decoder is temporarily overwhelmed, it emits bursts 
of "hard" (binary) errors that are well adapted to the capabilities of 
the Reed Solomon decoder. 


The Voyager concatenated coding system is fairly simple by modern 
standards and is well within our capability. I've already done the 
Viterbi decoder for the NASA standard r=1/2 K=7 convolutional code. 
N9FZX has done a Reed-Solomon decoder that may be the same one that 
Voyager uses, but I'm not sure. In any event, all you need to combine 
the two is some glue (interleaving, buffering, etc). The waterfall 
curve for the Voyager coding scheme is a nearly vertical wall at 
around 2-2.5dB. 


Galileo uses the same basic techniques, but taken to some wild 
extremes to squeeze the most out of the omnidirectional antenna since 
the failure of the main antenna. The convolutional code has r=1/4, 
K=14, which is extremely high for a Viterbi decoder (the work factor 
increases exponentially with K). And the RS code uses varying amounts 
of redundancy per block which permits a trick called "redecoding". 


First you run the Viterbi decoder. Then you run the RS decoder on the 
output. Some of the RS blocks will decode, some won't; the blocks 
with more redundancy being more likely to decode. You fill in the 
missing symbols in the decoded blocks and then toss them back to the 
Viterbi decoder for another go with the RS-decoded states "pinned 
down". Then you have a second go at the RS decoder. You iterate this 
perhaps 4-5 times until things stop improving. The end result is an 
astonishingly low Eb/NO requirement of about ©.56dB, damn near the 
Shannon limit for that channel. Of course, they do this at only 10 b/s 
on a Sparcstation... 


Phil 


From FORRERJ@frl.orst.edu Wed Jan 11 10:51:48 1995 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrS6Gv-OOO0OyNC; Wed, 11 Jan 95 10:51 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAAO04424 for <hfsig@tapr.org>; Wed, 11 Jan 1995 
01:30:11 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Wed, 11 Jan 95 8:50:18 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 11 Jan 95 8:50:14 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Wed, 11 Jan 1995 08:50:14 PST8PDT 
Subject: Re: [HFSIG:192] Re: HF Modulation 
Priority: normal 
X-mailer: PMail v3.0 (Ria) 


Message-ID: <D60CDC50F6D@fr1l.orst.edu> 
Hi Phil, 
That essay on coding was welcomed by everyone - well done! 


I would just like to add, if I may, one further thought relating 
specifically to the multitone signaling systems and coding methods. In a 
previous posting I mentioned the work by Pierce et, al. - nobody seems to 
have commented on that. Before it is lost - here is a brief summary: 


The fact that was established in this research paper, that was based on 
actual transatlantic and transcontinental HF data links at various HF 
frequencies, was that HF disturbances has somewhat characteristic 

nature, either broadband and/or noise bursts in conjunction with various 
forms of fading. This often has some frequency/sequency effects that could 
be put to good use in the type of coding applied, i.e. the choice of 
interleaving/constraint length for example. 


The second fact that the research established, was that channel spacing, 
(i.e. signaling over othoganally spaced channels) appears to have a 
systematic effect on BER. For example, if you look at BER vs. coding 
scheme, cyclic behavior with distinct minima is observed - that tells us 
that it is possible to optimise coding gain by proper choice of 

parameters, such as constraint length, interleave factor, and type of code. 


Taking these observations into account, as I have indicated in my earlier 
posting - an appropiate convolutional coder or the right type of block 

code was equally effective on parallel tone modems. This reseach was done 
prior to soft-decision coding becoming popular and I am sure other advances 
were made in coding theory since. 


There is no question that a combined block/convolutional code, possibly 
with soft-decision coding, will buy us the best of both worlds. Coding 
theory, however, is not one of the easiest of fields to wrestle with - for 
one, it does not allow the same degree of intuition or gut feeling to be 
applied as for instance modulation/demodulation theories. You really have 
to know what you are doing. 


I think we all agree that we are very much dependant on the guidance and 
contribuitions of experts like Phil. 


Looking forward to learning more about this field. 
73's 


Johan, KC7WW 


From jmorriso@bogomips.ee.ubc.ca Wed Jan 11 13:33:41 1995 

Return-Path: <bogomips.ee.ubc.ca! jmorriso@rflab.ee.ubc.ca> 

Received: from rflab.ee.ubc.ca by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrS8nR-O001PbC; Wed, 11 Jan 95 13:33 CST 

Received: from bogomips.ee.ubc.ca by rflab.ee.ubc.ca with uucp 
(Linux Smail3.1.28.1 #1) id mOrS81P-OQ000SFC; Wed, 11 Jan 95 11:31 PST 

Received: by bogomips.ee.ubc.ca (Linux Smail3.1.29.1 48) 
id mOrS8KB-0004gbC; Wed, 11 Jan 95 11:03 PST 

Message-Id: <mO0xrS8KB-0004gbC@bogomips.ee.ubc.ca> 

From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison) 

Subject: voice? 

To: hfsig@tapr.org 

Date: Wed, 11 Jan 1995 11:03:15 -0800 (PST) 

X-Linux: watch for Linux '95 aka "Helsinki" 

X-Bogomips: 33.55 

X-Mailer: ELM [version 2.4 PL22] 

Content-Type: text 

Content-Length: 836 


Will these 2400bps HF modems be able to work with digitized+compressed 
voice? (CELP or something). That would really be something to impress 
the regular (digital is for weenies) HFers! The answer should be 'yes' 
if the BER is reasonable and it would be ‘usable' if there's no long 
training sequence between modems (I mean you couldn't key up and say 
'QSL' or something short if it took 10 seconds to train every time). 


I don't know what's available in hardware voice compression etc., but 
the ICs are no doubt getting cheap. 


BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM_ -- 
jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org 


From shall@rain.org Wed Jan 11 14:41:55 1995 

Return-Path: <shall@rain.org> 

Received: from coyote.rain.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrS9rc-OOO1RxC; Wed, 11 Jan 95 14:41 CST 

Received: from by coyote.rain.org(4.1/SMI-RAIN) with id AB19335 

for hfsig@tapr.org on Wed, 11 Jan 95 12:36:59 PST 

Date: Wed, 11 Jan 95 12:36:59 PST 

Message-Id: <9501112036.AB19335@coyote.rain.org> 

X-Sender: shall@rain.org 

X-Mailer: Windows Eudora Version 2.0.3 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: shall@rain.org (Steve Hall) 


Subject: Re: [HFSIG:190] HF DSPs 
Victorio, 


If you would care to run any on the air tests on G-TOR to Southern California 
please let me know. 


Steve Hall, WM6P 


>I'm a new member of the list, and also new in data comm over HF. We will be 
establishing some HF links here in the Philippines using GTOR. I was told 
that there are DSP filter units (Timewave DSP 59+) useful for PACTOR and 
AMTOR links. I was wondering if the same DSP units can make a substantial 
improvement in performance when using the GTOR protocol. 

> 

>All commentaries and advise on this will be highly appreciated. 


>Victorio A. Ochave, Jr. 

>Communications Engineering Division 

>Advanced Science and Technology Institute (ASTI) 
>Department of Science and Technology (DOST) 

>4/F NEC Bldg., University of the Philippines 
>Diliman, Quezon City, PHILIPPINES 1101 

> 

>voice: 632 995071-9 loc.5106 

>fax: 632 9224714 

>Internet: jojo@asti.dost.gov.ph 

> ochave@itu.ch 

> v.ochave@ieee. org 

>X.400: G=victorio; S=ochave; P=itu; A=arcom; C=ch 


Steve Hall 


From FORRERJ@frl.orst.edu Wed Jan 11 14:43:13 1995 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxS90F-O001VPC; Wed, 11 Jan 95 14:38 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id FAA06132 for <HFSIG@tapr.org>; Wed, 11 Jan 1995 
05:06:19 -0Q800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Wed, 11 Jan 95 12:26:26 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 11 Jan 95 12:26:12 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 


Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Wed, 11 Jan 1995 12:26:08 PST8PDT 
Subject: Software tools for soundcard 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <D6467482522@frl.orst.edu> 
Hi all, 


For those folks working or planning to work with the PSA sound cards, here 
is some great news. 


According to a post on Usenet, version 5.01 of the Analog Devices' software 
development tools for the 21xx DSP is available via anonymous ftp. This 
toolkit is professional quality and include, amongst other things, the GNU C 
compiler, GNU assembler, linker, prom splitter, and simulator. Since I have 
purchased this software some time ago (without knowing that it was on the 
net), and used it extensively, I can highly recommend it. 


Only minor changes are necessary to the software that I have previously 

made available. In fact, the host code requires only commenting out one line 
of code. The DSP code requires a few changes - though nothing serious. The 
fact that you can now concentrate on your DSP application instead of 
concering yourself with how and where stuff gets loaded and cross-linked, 
makes programming the DSP a pleasure. 


The software tools are available at: ftp.analog.com in 

directory /pub/dsp/devtools/21xx. It's some 2.8 M, so beware. I downloaded 
it yesterday (1/10/95) to make sure it was'nt a hoax - its real OK, but I'm 
not sure whether this is an accident? 


Trust this is of interest. 
73's 


Johan, KC7WW 


From k5yfw@sacdm10.kelly.af.mil Wed Jan 11 14:54:42 1995 

Return-Path: <k5yfw@sacdm10.kelly.af.mil> 

Received: from sacdm10.kelly.af.mil by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrSA3y-0001XIC; Wed, 11 Jan 95 14:54 CST 

Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id m0rS9zi-0002BuC; Wed, 11 Jan 95 14:50 CST 

Message-Id: <m0xrS9zi-0002BuC@sacdm10.kelly.af.mil> 

Date: Wed, 11 Jan 95 14:50:14 -0600 

From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 

Subject: Re: [HFSIG:194] voice? 

To: hfsig@tapr.org 

X-orig-date: Wed, 11 Jan 95 13:42 CST 

X-orig-from: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison) 


X-orig-message-ID: <mO0rS8KB-0004gbC@bogomips.ee.ubc.ca> 


The MIL-STD-188-110A (39 parallel tone) modems were designed to do 
just that. In fact, the first 39 parallel tone modem I ever saw (in 
about 86 or 87) was in a voice encryption device. I believe the 
military used LCP10 voice encryption. -- k5yfw 


In your message of 11 Jan 1995 at 1342 CST, you write: 


Will these 2400bps HF modems be able to work with digitized+compressed 
voice? (CELP or something). That would really be something to impress 
the regular (digital is for weenies) HFers! The answer should be '‘'yes' 
if the BER is reasonable and it would be ‘usable' if there's no long 
training sequence between modems (I mean you couldn't key up and say 
'QSL' or something short if it took 10 seconds to train every time). 


I don't know what's available in hardware voice compression etc., but 
the ICs are no doubt getting cheap. 


VVVV VV VV VV VV NV 


Vv 


> BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM_ -- 
> jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org 
> wee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee eB ee ee ee ee ee ee ee ee ee ee ee ee ee ee eee 
> 

From esilbaug@afit.af.mil Wed Jan 11 16:11:15 1995 

Return-Path: <esilbaug@afit.af.mil> 

Received: from stealth.afit.af.mil by dptspd.sat.datapoint.com with smtp 


(Smail3.1.29.1 #5) id mOxSBG4-0001L5C; Wed, 11 Jan 95 16:11 CST 
Received: from grouse.afit.af.mil by stealth.afit.af.mil with SMTP id AA24672 
(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Wed, 11 Jan 1995 17:11:09 -0500 
Date: Wed, 11 Jan 1995 17:11:09 -0500 
From: Eric E Silbaugh <esilbaug@afit.af.mil> 
Message-Id: <199501112211.AA24672@stealth.afit.af.mil> 
To: hfsig@tapr.org 
Subject: Peak Reduction (was RE: HF Modulation) 
Cc: esilbaug@afit.af.mil 


Al, 


I agree, "...lower average power means less interference to other users. 

I would just add the phrase ",except during the peaks". Think about it this 
way. Take the total energy in a "peaky" signal and spread it evenly across 
the entire symbol period. This is analogous to Phil's scheme of spreading 
the energy evenly over frequency, just in the time domain. This would give 
a signal with the same energy and even less interference. 


Speaking of my "naive" phase randomization method, you wrote: 


> The "naive method" may be pretty close to optimal. ..... 


I hope not, but I don't know a better way (yet). As you point out, a single 
sinusoid has a 1.5 dB peak-to-RMS ratio and is probably the lower limit. 
Randomizing the initial phases in my simulation gave an average 5 dB peak-to- 
RMS ratio. There is room for improvement. How much improvement we can obtain, 
and how to do it practically, are open questions. 


This may just be my SATCOM background coming back to haunt me. Satellite 
transponders can be very nonlinear. Constant envelope modulation methods 

are widely used because they are distorted less and produce less interference 
to other users on the same transponder. 


The whole question of whether reducing the peak-to-RMS ratio provides real 

benefits is another open question. Probably the best way to find out is to 
start testing these methods over the air and on Johan's channel simulator. 

Radio amateurs, start your modems! 


Eric, N2NNP 


= 2 a Eric E. Silbaugh 
: ae esilbaug@afit.af.mil 


: ae All standard, non-standard, and 
SOME Pa PEST es MIL-STD disclaimers apply 
From esilbaug@afit.af.mil Wed Jan 11 16:12:24 1995 
Return-Path: <esilbaug@afit.af.mil> 
Received: from stealth.afit.af.mil by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxSBHA-OO001VPC; Wed, 11 Jan 95 16:12 CST 
Received: from grouse.afit.af.mil by stealth.afit.af.mil with SMTP id AA24707 
(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Wed, 11 Jan 1995 17:12:13 -0500 
Date: Wed, 11 Jan 1995 17:12:13 -0500 
From: Eric E Silbaugh <esilbaug@afit.af.mil> 
Message-Id: <199501112212.AA24707@stealth.afit.af.mil> 
To: hfsig@tapr.org 
Subject: Peak Reduction (was RE: HF Modulation) 
Cc: esilbaug@afit.af.mil 


Johan, 
Just curious, what surprised you about your radio's audio response? 


About your FFT and clipping. Think about each frequency bin as a channel in 
a satellite transponder, and each tone as a channel being used. Now send 
this through a nonlinear transponder that limits the composite signal. Those 
intermodulation products cause serious problems. You just saw what a SATCOM 
engineer faces trying to make a DAMA (demand assigned, multiple access) 
network useable. Whether IMD will affect HF modems remains to be seen. I 
suspect it will, negatively. 


I think M-ary orthogonal FSK or OFDM (whatever you want to call it) has 

potential as a simple and robust modulation method for DSP-based HF modems. 
The FFT seems to be a natural algorithm for this. We also have the working 
examples of Clover and the MIL-STD modems to guage our performance against. 


Eric, N2NNP 


= 2 = Eric E. Silbaugh 
: eee bac esilbaug@afit.af.mil 


: fe All standard, non-standard, and 
Sea ee ees MIL-STD disclaimers apply 
From FORRERJ@frl.orst.edu Wed Jan 11 17:51:26 1995 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrSCp0-0001ZAC; Wed, 11 Jan 95 17:51 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id IAA07529 for <hfsig@tapr.org>; Wed, 11 Jan 1995 
08:29:48 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Wed, 11 Jan 95 15:49:55 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 11 Jan 95 15:49:49 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Wed, 12 Jan 1995 15:49:41 PST8PDT 
Subject: Re: ICOM 751 Filter response curves 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <D67CC315CCE@frl.orst.edu> 
Hi Eric, 


What surprized me was to see the different filter responses for "RTTY" and 
"LSB". RTTY mode gave a fairly steep shirt starting around 1500 Hz, then 
tapered off, nearly in a linear fashion, down to 4kHz - no "flat top" at 
all. LSB, on the other hand, contained a band between approximaely 300 

Hz and 2600 Hz, though not a very clean filter response shape. If, for 
instance, the full 3kHz is required for a parallel modem, there would be 
some impact on the channels closer to the band edges. 


What I am seeing, of course, is a result of the rig's audio output 
response at the headphone jack as well as the sound card's audio input 
response. Perhaps a better place to tap this audio would be at a 

point before the audio stages. 


The tests were mainly to play with the real-time FFT scope and is actually 
the same DSP code used in the parallel modem demodulator. Fun stuff. 


Johan, KC7WW 


From k5yfw@k5yfw.ampr.org Wed Jan 11 21:36:13 1995 

Return-Path: <k5yfw@k5yfw.ampr.org> 

Received: from k5yfw.ampr.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxSGJA-O000sJC; Wed, 11 Jan 95 21:34 CST 

Date: Wed, 11 Jan 95 21:05:25 CST 

Message-Id: <2471@k5yfw.ampr.org> 

From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW) 

Reply-To: k5yfw@sat.n5lyt.ampr.org 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:200] Re: ICOM 751 Filter response curves 

In-Reply-To: Your message of Wed, 11 Jan 95 17:54 CST 

X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS) 


In message <D67CC315CCE@frl.orst.edu> Johan writes: 
Hi Eric, 


What surprized me was to see the different filter responses for "RTTY" and 
"LSB". RTTY mode gave a fairly steep shirt starting around 1500 Hz, then 
tapered off, nearly in a linear fashion, down to 4kHz - no "flat top" at 
all. LSB, on the other hand, contained a band between approximaely 300 

Hz and 2600 Hz, though not a very clean filter response shape. If, for 
instance, the full 3kHz is required for a parallel modem, there would be 
some impact on the channels closer to the band edges. 


VV VV VV VV V 


The AN/URC-119 (Harris RF-350) HF military/commercial 
transceiver has 3 KHz SSB filters...one of each sideband. I 
have run IF bandpass checks on them and they have a very clean 
response and quite a sharp cutoff above 3 KHz...much cleaner 
than amateur equipment as noted above. This might mean that 
some BW less than 3 KHz would be needed of compensation for the 
upper 1 KHz of the IF bandpass. 


What I am seeing, of course, is a result of the rig's audio output 
response at the headphone jack as well as the sound card's audio input 
response. Perhaps a better place to tap this audio would be at a 

point before the audio stages. 


VV VV V 


The AN/URC-119 (Harris RF-350) has an audio jack that bypasses 
the speaker audio stages and mic. amp. stages. The audio there 
is much cleaner that at the mic. or headphone jacks. This is 
where they connect the MIL-STD-188-110A (39 tone) modem. 


On my IC-735, I have found that the audio jacks on the back 
panel provide much cleaner audio for data work. I don't know if 
the IC-751 has such a jack. 


The tests were mainly to play with the real-time FFT scope and is actually 
the same DSP code used in the parallel modem demodulator. Fun stuff. 


VV VV 


The MIL-STD modems require 10 Hz dial resolution read-out but the 
frequency *MUST*x be within about 3 or 4 Hz to the modems to work 
correctly. That would require some kind of "on-screen" tuning 
for use with an amateur radio...except for something like the 
SGC-2000 or Kenwood TKM-707 which are commercial radios with the 
SGC meeting MIL-Specs. 


Walt@home.2.nite 

From karn@qualcomm.com Thu Jan 12 01:21:24 1995 

Return-Path: <karn@qualcomm. com> 

Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrSJqT-O000XqC; Thu, 12 Jan 95 01:21 CST 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id XAA05968; 

Wed, 11 Jan 1995 23:23:22 -0800 

Date: Wed, 11 Jan 1995 23:23:22 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199501120723.XAAQ5968@servo.qualcomm. com> 

To: hfsig@tapr.org 

Subject: More on Galileo coding 


Here's an abstract I found on a NASA web server that summarizes the 
coding tricks they're using to milk the most out of the low-gain 
antenna on Galileo. Of course, the deep space channel is very 
different from the HF channel, but it gives you an idea of what coding 
can do. 


Enhanced decoding for the Galileo S-band mission 


DOLINAR, S.; BELONGIE, M. 


Jet Propulsion Lab., California Inst. of Tech., Pasadena, CA. 


Published: August 1993 Pages: 00016 Biblio Refs: 0 


A coding system under consideration for the Galileo S-band low-gain 
antenna mission is a concatenated system using a variable redundancy 
Reed-Solomon outer code and a (14,1/4) convolutional innexr code. The 
8-bit Reed-Solomon symbols are interleaved to depth 8, and the eight 
255-symbol codewords in each interleaved block have redundancies 64, 
20, 20, 20, 64, 20, 20, and 20, respectively (or equivalently, the 
codewords have 191, 235, 235, 235, 191, 235, 235, and 235 8-bit 
information symbols, respectively). This concatenated code is to be 
decoded by an enhanced decoder that utilizes a maximum likelihood 
(Viterbi) convolutional decoder; a Reed Solomon decoder capable of 
processing erasures; an algorithm for declaring erasures in undecoded 
codewords based on known erroneous symbols in neighboring decodable 
words; a second Viterbi decoding operation (redecoding) constrained 
to follow only paths consistent with the known symbols from 
previously decodable Reed-Solomon codewords; and a second Reed- 
Solomon decoding operation using the output from the Viterbi 


redecoder and additional erasure declarations to the extent possible. 
It is estimated that this code and decoder can achieve a decoded bit 
error rate of 1 x 10(exp 7) at a concatenated code signal-to-noise 
ratio of 0.76 dB. By comparison, a threshold of 1.17 dB is required 
for a baseline coding system consisting of the same (14,1/4) 
convolutional code, a (255,223) Reed-Solomon code with constant 
redundancy 32 also interleaved to depth 8, a one-pass Viterbi 
decoder, and a Reed Solomon decoder incapable of declaring or 
utilizing erasures. The relative gain of the enhanced system is thus 
@.41 dB. It is predicted from analysis based on an assumption of 
infinite interleaving that the coding gain could be further improved 
by approximately 0.2 dB if four stages of Viterbi decoding and four 
levels of Reed-Solomon redundancy are permitted. Confirmation of this 
effect and specification of the optimum four-level redundancy profile 
for depth-8 interleaving is currently being done. Author (revised) 
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From karn@qualcomm.com Thu Jan 12 18:40:15 1995 

Return-Path: <karn@qualcomm. com> 

Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrSa3p-00018qC; Thu, 12 Jan 95 18:40 CST 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id QAA15580; 

Thu, 12 Jan 1995 16:42:12 -0800 

Date: Thu, 12 Jan 1995 16:42:12 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199501130042.QAA15580@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <2428@k5yfw.ampr.org> 

Subject: Re: [HFSIG:174] Re: HF modulation 


> Boy does the signal ever sound like noise...as you tune across 
> the signal the S meter will rise and fall and you will think you 
> are just tuning a noisy frequency. 


A year or so ago somebody on the cypherpunks list came up with the 
following wonderful adaptation of Clarke's famous saying that "any 
sufficiently advanced technology is indistinguishable from magic": 


"Any sufficiently advanced communication is indistiguishable from noise". 


This is actually implied by Shannon's theory. The more efficient a 
modulation/coding method is, the more noiselike it must become. The 
reverse is not necessarily true (just because it's noiselike doesn't 
mean it's efficient). 


Phil 


From karn@qualcomm.com Fri Jan 13 15:58:32 1995 

Return-Path: <karn@qualcomm. com> 

Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrSuO0q-QQOQOQUZC; Fri, 13 Jan 95 15:58 CST 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id OAA25848; 

Fri, 13 Jan 1995 14:00:25 -0800 

Date: Fri, 13 Jan 1995 14:00:25 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199501132200.0AA25848@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <D60CDC50F6D@frl.orst.edu> (FORRERJ@fr1.orst.edu) 

Subject: Re: [HFSIG:193] Re: HF Modulation 


>Taking these observations into account, as I have indicated in my earlier 
>posting - an appropiate convolutional coder or the right type of block 
>code was equally effective on parallel tone modems. This reseach was done 
>prior to soft-decision coding becoming popular and I am sure other advances 
>were made in coding theory since. 


Soft-decision decoding wins especially big on fading channels, by the 
way. As I mentioned in my discussion, convolutional decoding is much 
more easily adapted to soft decision decoding. It's almost universal 
in Viterbi decoding, somewhat less so in sequential because of its 
greater sensitivity to gain errors. 


Soft decision decoding can be adapted to block codes, but with 
considerably greater difficulty. The technique is called "Chasing 
bits", after David Chase, the inventor. Basically, you determine your 
N weakest received symbols. Then you try decoding all 24N possible 
values of these weak symbols (for a binary code) along with the 
"strong" received symbols. Take each decoded block, re-encode it and 
pick the result that's closest in Hamming distance to the original 
received block of symbols. 


Obviously the complexity goes up exponentially with N. That can really 
stress your block decoding software. 


Non-binary codes like Reed Solomon codes can be "softened" somewhat by 
simply erasing your weakest symbols. Since a RS code can correct twice 


as many symbol erasures as errors, you stand an improved chance of 
decoding the block correctly. 


Erasure decoding on a binary channel can be seen as soft-decision 
decoding with only 3 symbol values: "1", "OQ" and "unknown". A little 
"softness" goes a long way; just adding an erasure indication is a big 
win, especially on deep fading channels. In my experiments with rate 
1/2 sequential Fano decoding, I found I could barely handle 8-9% 
symbol errors on a hard-decision binary channel. But if I introduced 
erasures rather than errors, I could tolerate nearly 50% erasures. 


One way to implement erasure decoding even when you don't have a 
3-level channel is to send a packet twice and compare the two. You 
erase any symbols that don't match. 


Phil 
From FORRERJ@frl.orst.edu Fri Jan 13 22:37:27 1995 
Return-Path: <FORRERJ@frl1.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrTOEs-0001YsC; Fri, 13 Jan 95 22:37 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id NAA20885 for <hfsig@tapr.org>; Fri, 13 Jan 1995 
13:15:10 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Fri, 13 Jan 95 20:35:23 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Fri, 13 Jan 95 20:35:22 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Fri, 13 Jan 1995 20:35:15 PST8PDT 
Subject: Re: [HFSIG:204] Re: HF Modulation 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <D9C90023B27@frl.orst.edu> 
Hi Phil, 


I have been making good progress with the parallel DSP modem - a few tricks 
on the tone generation and it actually now sounds a little musical, 

perhaps a little warbly - this is an 8 channel version that fits into 250 Hz 
and has a raw bit rate of 1000 bps - At the moment I'm testing things by 
running the the modem in full duplex with loopback. 


Phil has been making excellent contributions on coding methods - in 
addition, we also have to start discussing the data link layer in all 
seriousness. I would suggest that the first attempt be at a simple FEC 
method but are open to any suggestions? 


73's 


Johan, KC7WW 


From frode@dxcern.cern.ch Wed Jan 18 09:28:39 1995 

Return-Path: <frode@dxcern.cern.ch> 

Received: from dxmint.cern.ch by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrUcJA-OOOOExC; Wed, 18 Jan 95 09:28 CST 

Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA17517; Wed, 18 Jan 1995 16:28:19 +0100 

Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA25255; Wed, 18 Jan 1995 16:28:16 +0100 

From: frode@dxcern.cern.ch (Frode Weierud) 

Message-Id: <9501181528 .AA25255@dxcern.cern.ch> 

Subject: Re: [HFSIG:205] Re: HF Modulation 

To: hfsig@tapr.org 

Date: Wed, 18 Jan 1995 16:28:15 +0100 (MET) 

In-Reply-To: <D9C90023B27@frl.orst.edu> from "Johan Forrer 

FL" at Jan 13, 95 10:44:00 pm 

X-Mailer: ELM [version 2.4 PL23] 

Mime-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 

Content-Length: 1400 


Hi all, 


> I have been making good progress with the parallel DSP modem - a few tricks 
> on the tone generation and it actually now sounds a little musical, 

> perhaps a little warbly - this is an 8 channel version that fits into 250 Hz 
> and has a raw bit rate of 1000 bps - At the moment I'm testing things by 

> running the the modem in full duplex with loopback. 


Phil has been making excellent contributions on coding methods - in 
addition, we also have to start discussing the data link layer in all 
seriousness. I would suggest that the first attempt be at a simple FEC 
method but are open to any suggestions? 


VVV Vv 


It appears to be that fragments of code are growing in several 
corners of the HFSIG list, such as Johan's channel simulator code, 
Johan's DSP code for the MIL-STD-188-110A parallel tone modem and 
Phil's code for the Viterbi algorithm. 


I for one would like very much to have a peek at this code to play 
around a bit, get my hands ‘dirty' and get some experience. Would 

it be possible to arrange an Anonymous FTP server somewhere where 
the list members could dump their code, data files, documents etc. 
and where we all can have easy access. I agree that lot of the code 
will be experimental and not in a form fit for public distribution, 
but on a UNIX host it is very easy to arrange for a hidden directory 


to house our not yet consumer ready code. 


73 Frode, LA2RL 
From FORRERJ@frl.orst.edu Wed Jan 18 10:56:54 1995 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrUdgh-00019GC; Wed, 18 Jan 95 10:56 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAAO06939 for <hfsig@tapr.org>; Wed, 18 Jan 1995 
01:34:22 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Wed, 18 Jan 95 8:54:46 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 18 Jan 95 8:54:36 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Wed, 18 Jan 1995 08:54:34 PST8PDT 
Subject: Re: [HFSIG:206] Re: HF Modulation 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <EQ8E528710B@frl.orst.edu> 
Hi Frode, 
<some lines deleted> 


> 

>It appears to be that fragments of code are growing in several 
>corners of the HFSIG list, such as Johan's channel simulator code, 
>Johan's DSP code for the MIL-STD-188-110A parallel tone modem and 
>Phil's code for the Viterbi algorithm. 

> 

>I for one would like very much to have a peek at this code to play 
>around a bit, get my hands ‘dirty' and get some experience. Would 
>it be possible to arrange an Anonymous FTP server somewhere where 
>the list members could dump their code, data files, documents etc. 
>and where we all can have easy access. I agree that lot of the code 
>will be experimental and not in a form fit for public distribution, 
>but on a UNIX host it is very easy to arrange for a hidden directory 
>to house our not yet consumer ready code. 

> 

>73 Frode, LA2RL 


Thanks for bringing this up - Greg suggested we use tcet.unt.edu in 

the mean time and I checked and found that there indeed was a TAPR 
subdirectory. I am not sure what the future plans are for a permanent home 
for these code fragments. 


The bits and pieces that I have is rather experimental and at this stage 
would like to hang on a bit before placing it on an anonymous ftp site. 
However, I have been sharing the source code with whoever asked for it, 


at least I can warn them ahead of time of what they are in for. Please 
feel free to request the code. 


I have a "C" version of the HF channel simulator as well as the beginnings 
of a DSP version for the sound card DSP. The "C" simulation of the OFDM 
modem is probably the easiest to understand and allows you to modify it 

to your liking. The DSP version is more involved as it has to deal with 
optimized stuff like the radix-4 FFT and multitone signal synthesis. You 
would also need the sound card and the ADI development tools to do any 
work on it. I also have several programs that deal with Golay(24,12), 
Reed-Solomon, and BCH block codes. 


Phil promised that he would be making his convolutional coding program 
available after doing some cleanup work. I am quite interested in trying 
that with the OFDM modem. 


I also suggest looking at Eric's OFDM simulations - it is very enlightening. 
73's 


Johan, KC7WW 

From gjones@tenet.edu Wed Jan 18 16:28:16 1995 

Return-Path: <gjones@tenet.edu> 

Received: from Alice-Thurman.tenet.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrUirA-OOOOQUfC; Wed, 18 Jan 95 16:28 CST 

Received: (from gjones@localhost) by Alice-Thurman.tenet.edu (8.6.9/8.6.9) id 

QAA09979 for hfsig@tapr.org; Wed, 18 Jan 1995 16:27:57 -0600 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199501182227 .QAA09979@Alice-Thurman.tenet.edu> 

Subject: Re: [HFSIG:207] Re: HF Modulation 

To: hfsig@tapr.org 

Date: Wed, 18 Jan 1995 16:27:56 -0600 (CST) 

In-Reply-To: <E08E528710B@frl.orst.edu> from "Johan Forrer 

FL" at Jan 18, 95 11:13:00 am 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 737 


According to Johan Forrer 

FL: 

> Thanks for bringing this up - Greg suggested we use tcet.unt.edu in 

> the mean time and I checked and found that there indeed was a TAPR 

> subdirectory. I am not sure what the future plans are for a permanent home 
> for these code fragments. 


ftp.tapr.org should be registered as a mx record later today and should be 
availble for access shortly, once the it distributed fully (figure a few 
days). 


HF SIG will have a location for this type of thing. I'll let you know when 
we I think it is all operational. Johan will get a special login so that you 
can manage the area. 


/tapr/SIG/hfsig 
Should be better than TCET :-) 


Greg 

From bm@lynx.ve3jf.ampr.org Wed Jan 18 20:08:18 1995 

Return-Path: <bm@lynx.ve3j£.ampr.org> 

Received: from hydra.carleton.ca by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxUmIH-O0000dtC; Wed, 18 Jan 95 20:08 CST 

Received: from lynx.ve3jf.ampr.org (root@lynx.ve3jf£.ampr.org [44.135.96.100]) by 

hydra.carleton.ca (8.6.9/8.6.9) with SMTP id VAA22916 for <hfsig@tapr.org>; Wed, 

18 Jan 1995 21:08:03 -0500 

Received: by lynx.ve3jf.ampr.org (Linux Smail3.1.28.1 #14) 
id mOrUmI3-0002hbC; Thu, 19 Jan 95 02:07 GMT 

Message-Id: <m0xrUmI3-0002hbC@lynx.ve3j£.ampr.org> 

From: bm@lynx.ve3j£.ampr.org (Barry McLarnon VE3JF) 

Subject: Re: HF modulation 

To: hfsig@tapr.org 

Date: Thu, 19 Jan 1995 02:07:56 +0000 (GMT) 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 9052 


[I sent this a few days ago, but it seems to have vanished in 
cyberspace... I guess because of the listserver changeover. Try, try 
again... ] 


I only tuned into this mailing list quite recently, so I'm just starting 
to catch up on some of the discussions. This message caught my eye: 


Phil's intriguing proposal for using M-ary orthogonal FSK 
with Walsh functions. Over Christmas break (I'm pursuing 
an MSEE; if only I could catch it) I did some crude 
simulations of Phil's scheme using MATLAB. 


First, I generated a 64x64 Hadamard matrix (whose rows are 
Walsh functions). Then I generated 64 equal amplitude 
sinusoids, each separated by 32 Hz, from 512 Hz to 2528 Hz. 
I then picked a row at random from the Hadamard matrix to 
determine which sinusoids to sum together. I sampled the 
time sequence at 32 kHz and plotted it over a full period 
of the combined signal. 


I used several different Walsh functions to get a feel for 
the general behavior of these signals. Since I started with 
64 tones, and only 1/2 are on for any particular Walsh 
function, I was combining 32 separate tones. The results 
were rather interesting, and very similar to Johan's. 


Thus wrote Johan, KC7WW: 


> AS a way to learn more about how OFDM works for the 
> 39-tone MIL-STD-188 parallel modem, I wrote a C program 


VV VV VV VV VV VV VV VV VV VV VV OV 


> that simulates 39 parallel tones and combines them into 
> a Single output signal. 


[snip] 


I also did capture the simulated output waveform and was 
quite concerned after inspecting the plot - the 
presence of large spikes of significant magnitude (in 
some cases, some 10-15 dB over the RMS value). 


VVV NV 


My simulation produced signals with peak-to-RMS ratios of 

9 dB, they were generally of low amplitude except where 

the sinusoids came into phase and produced a large peak, 
and they generally looked 'noiselike'. I also noticed that 
the signal's peak amplitude was not symetric about the time 
axis. The signals had zero average value but the largest 
positive-going peak was twice as high as the largest 
negative-going peak. 


VV VVV VV VV VV VV VV VV MV 


Are you sure about the 9 dB? A 32-tone signal should have a peak-to-RMS 
ratio (aka "Crest Factor") of 18 dB for the case in which all of the 

tones have zero initial phase shift. The formula for the Crest Factor for 
N tones is: 


CF = sqrt(2N), or in dB, 20 log CF. 


As several others have noted, this high peak-to-RMS ratio 
will limit the amount of energy per symbol. A signal such 
as this is potential trouble in any amplifier unless care is 
taken to control the peak level. The asymetry in peak 
heights may furthur limit the amount of power an amplifier 
could deliver. This is definitely not a constant envelope 
signal so linear amplifiers are in order. As more tones are 
added the signals will have larger peak-to-RMS ratios. This 
is consistent with Johan's observations since he was summing 
more tones. 


The FCC limits amateurs based on PEAK envelope power (PEP), 
not RMS power. As Phil noted, coding gains can buy back 
most of the loss in energy per symbol caused by the low RMS 
value of the signal, but it's still a significant limitation. 
Disregarding interference, it's ultimately the energy per 
bit that determines the performance of a digital system. 


Phil's proposal was for a noncoherent system, which got me 
thinking (scary, eh?). A noncoherent system ignores the 
phase of a signal; so, we have a free parameter to play with. 
My initial simulation started each sinusoid at zero phase. 

If we could use the phase to reduce the peak value of the 
signal we could get more energy per symbol and get the coding 
gain as well. 


VV VV VV VV VV VV VV VV VV VV VV VV VV WV 


First I tried a linear shift in the initial phase across all 


64 sinusoids. I started with zero initial phase at the lowest 
frequency and increased the phase linearly to two pi at the 
highest frequency. This resulted in signals with about the 
same peak-to-RMS ratios (8.25 dB), still 'noiselike', but the 
amplitude peaks became symetrical about the time axis 
(interesting and unexpected). 


VV VV VV 


According to the reference I have (see end of this message), the CF 
remains at sqrt(2N) in the case of phase shifts which vary linearly with 
frequency, so it should still be 18 dB. 


My next attempt was to assign a random initial phase to 

each of the 64 sinusoids. The initial phase was distributed 
uniformly between zero and two pi. This produced signals with 
an average peak-to-RMS ratio of 4.75 dB, the signals looked 
extremely 'noiselike', and the amplitude peaks were nearly 
symetrical. Progress! 


VV VV VV 


I think this is again off by a factor of two, but it illustrates that 
random phase is certainly a better choice... in this case, the 
dependency of CF on N is of the order of sqrt(log N) instead of sqrt(N). 


These were just the first ways I thought of to change the 
phase, there was no method to my maddness. Even a naive 
method like ramdomizing the phase produced a 4 dB reduction 
in the peak-to-RMS ratio. These results lead to a conjecture 
and several questions. 


My conjecture is that we can reduce the peak-to-RMS ratio 
further, and maybe even approximate a constant envelope 
signal, by properly choosing the phases of the sinusoids. 
I think this is plausible since a wideband FM signal is a 
constant envelope signal and its spectrum looks like a set 
of nearly equal amplitude sinusoids, within a limited 
bandwidth. I doubt we could get a truly constant envelope 
signal because we are using a small set of harmonically 
related sinusoids. 


VV VV VV VV VV VV VV WV 


Your conjecture is correct. :-) 


Some questions I have: 


> 
> 

> - Are there systematic methods for choosing the 

> initial phases of the sinusoids to minimize the 

> peak-to-RMS ratio? 

Yes. See the paper by Boyd referenced below. A proof exists that, in 

the case where N is a power of 2, a set of phases can be found which 

yields a Crest Factor of under 6 dB for arbitrarily large N. Moreover, 

he gives a procedure for selecting phases which yields a CF of about 4.6 

dB for xanyx N (except when N is very small). The waveform generated by 
this procedure is fascinating: it closely resembles a chirp signal (constant 
envelope swept frequency, sometimes used as a spread spectrum technique). 


> - What limits are there on reducing the peak-to-RMS 
> ratio? 


According to Boyd, there is evidence that the ultimate limit is around 3 
dB, but no systematic method for finding the phases exists (yet). A 
colleague of mine did some work a few years back on numerical methods 
for finding near-optimum phases for multitone modems. He used an 
example of a 12-tone FSK modem (i.e., 12 simulaneous narrow-shift FSK 
signals with regular frequency spacing - one of the CCIR standards) and 
was able to find phase choices which yielded a CF in the 4-5 dB range 
for all 4096 possible frequency combinations. This would be a 
considerable improvement over the 13.8 dB CF you'd get with linear 
phases. 


> - Are these limits, if they exist, related to the 
> number of sinusoids or the Walsh function used? 


The limits seem to be independent of N, as long as N exceeds some 
minimum number (of the order of 10-20). 


> - Is this a well-known (or obscure) problem that 
> already has a solution? 


It's on the obscure side, but certainly some work has been done. I 
haven't been involved in HF data comms for quite a few years, so I don't 
know what recent advances might have been made in multitone modems... 
but I can ask around a bit. 


> - Is reducing the peak-to-RMS ratio really as 
important as I seem to think it is? 


Vv 


I'd say it's certainly worth further investigation... with the processing 
power now available in DSP's, control of the CF seems a lot more 

feasible than it used to be. Sometimes higher average power will buy 

you an improvement in BER, and sometimes it won't (when you've hit an 
irreducible error rate due to intersymbol interference from multipath), 
but overall it would be a win. 


The MIL-STD modems apparently use PSK on the tones as well. 
Since the phase of any particular sinusoid in my simulation 
was constant over the symbol period this should allow using 
methods such as DPSK on the tones if someone wants to add an 
additional layer of modulation. Would this increase the 
peak-to-RMS ratio? 


VVVVV WV 


I'm pretty sure it would, since you're now putting an additional 
constraint on the phases. If you want to Keep It Simple, stick with 
noncoherent FSK (which generally works at least as well as DPSK in 
multitone HF modems anyway). 


References: 


S. Boyd, "Multitone signals with low crest factor", IEEE Trans. on 
Circuits and Systems, vol. CAS-33, no. 10, October 1986, pp. 1018-1022. 


S. Shlien, "Minimization of the Peak Amplitude of a Waveform", _Signal 
Processing_, vol. 14, no. 1, January 1988, pp. 91-93. 


> Eric, N2NNP 


Barry 


Barry McLarnon VE3IF/VA3TCP 
Ottawa Amateur Radio Club Packet Working Group 
Email: bm@hydra.carleton.ca or bm@lynx.ve3jf£.ampr.org 
From FORRERJ@frl.orst.edu Thu Jan 19 11:40:05 1995 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrVOq2-0000FUC; Thu, 19 Jan 95 11:40 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
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Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 19 Jan 95 9:38:04 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£r1l.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Thu, 19 Jan 1995 09:38:03 PST8PDT 
Subject: Re: [HFSIG:209] Re: HF modulation 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <E219F550CBF@frl.orst.edu> 


Barry McLarnon VE3JF/VA3TCP wrote: 


> [I sent this a few days ago, but it seems to have vanished in 
> cyberspace... I guess because of the listserver changeover. Try, try 
> again... ] 


This appears to happen occasionally - please just keep trying. 
> I only tuned into this mailing list quite recently, so I'm just starting 
> to catch up on some of the discussions. This message caught my eye: 


<...lines deleted...> 


Welcome aboard Barry - looking forward to your contributions. 


73's 
Johan, KC7WW 


From BLOOM_ALAN/HP5300_RO@opnmail3.corp.hp.com Thu Jan 19 13:04:53 1995 
Return-Path: <BLOOM_ALAN/HP5300_RO@opnmail3.corp.hp.com> 
Received: from hp.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxV2A6-00018CC; Thu, 19 Jan 95 13:04 CST 
Received: from opnmail3.corp.hp.com by hp.com with SMTP 
(1.37.109.14/15.5+ECS 3.3) id AAQ0Q3142285; Thu, 19 Jan 1995 11:04:45 -0800 
Received: from by opnmail3.corp.hp.com with SMTP 
(1.37.109.8/15.5+ECS 3.3) id AAQ1912; Thu, 19 Jan 1995 11:04:44 -0800 
From: BLOOM_ALAN/HP5300_RO@opnmail3.corp.hp.com 
X-Openmail-Hops: 2 
Date: Thu, 19 Jan 95 11:04:00 -0800 
Message-Id: <dQeHfbYOQOQOQQ00@MHS> 
Subject: [HFSIG:209] Re: HF modulation 
To: hfsig@tapr.org 


Barry McLarnon VE3JF (bm@lynx.ve3j£,ampr.org) wrote: 


>> My simulation produced signals with peak-to-RMS ratios of 
>> 9 cB, 


>Are you sure about the 9 dB? A 32-tone signal should have a peak-to-RMS 
>ratio (aka "Crest Factor") of 18 dB for the case in which all of the 
>tones have zero initial phase shift. The formula for the Crest Factor for 
>N tones is: 


>CF = sqrt(2N), or in dB, 20 log CF. 


Note that this is the ratio of the peak power at the top of the sine wave(s) 
to the total RMS power. The PEP to RMS ratio will be 3 dB lower. 


Even a single pure sine wave has a peak-to-RMS ratio of 3 dB. 


AL N1AL 

From chbrain@dircon.co.uk Thu Jan 19 13:44:10 1995 

Return-Path: <chbrain@dircon.co.uk> 

Received: from felix.dircon.co.uk by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrV21r-00016YC; Thu, 19 Jan 95 13:43 CST 

Received: by felix.dircon.co.uk id AA24765 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 19 Jan 1995 19:44:07 GMT 

Date: Thu, 19 Jan 1995 19:44:07 GMT 

Message-Id: <199501191944.AA24765@felix.dircon.co.uk> 

Received: from aa006.pool.dircon.co.uk(193.128.228.6) by amnesiac via smap (V1.3) 
id smaQ24754; Thu Jan 19 19:43:47 1995 

X-Sender: chbrain@dircon.co.uk 

X-Mailer: Windows Eudora Version 1.4.3b4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 


To: hfsig@tapr.org 
From: chbrain@dircon.co.uk (Charles Brain) 
Subject: 8ary FEK modem 


Hi all, 

Just b4 xmas I started trying to do a bit of DSP programming on a TMS320C50 
DSK. 

I thought I would try to write an 8 ary modem a la MIL-STD 188-141A. I am using 
a 10 Khz sample rate (mainly because all the ALE tones are multiples of 250Hz) 
and I use the sample rate to generate the 8ms pulse periods table lookups etc. 

Well the Golay coding / triple redundancy and tone generation seems to work 
fine. 

However my idea of using 8 iir bandpass filters seems to have been a total 
disaster! Mainly as I can only use 2nd order filters in the available time. 

I had thought of using Goertzels algorithm commonly used in DTMF decoder 
algorithms, but from what I have read 8ms doesn't seem to be long enough to 
decode the tones. 

I could use an FFT I guess, but how do I get bit synchronisation? What ever 
method I use I need to get bit sync. 

Anyone got any ideas on how best to synchronise and decode these tones? 


Excuse my ignorance but this is the first DSP application I have tried to write. 


By the way Phil thanks for the Specs, I got them last week, maybe after I get 
this working I will start on them next!! 


Regards Charles G4GUO 


"projects don't slip, they just catch up with reality" 


Charles Brain (G4GUO) 
Chelmsford, Essex. 

E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 

FAX +44 (0)1245 275448 


From FORRERJ@frl.orst.edu Thu Jan 19 21:02:30 1995 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrV9cI-0000iZC; Thu, 19 Jan 95 21:02 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id LAA18421 for <hfsig@tapr.org>; Thu, 19 Jan 1995 
11:40:24 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Thu, 19 Jan 95 19:00:51 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 19 Jan 95 19:00:33 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Thu, 19 Jan 1995 19:00:26 PST8PDT 


Subject: Re: [HFSIG:212] 8ary FEK modem 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 

Message-ID: <E2AFF881204@frl.orst.edu> 


Hi Charles, 


Well thats excellent work! I think you will find this an interesting 
excersise. 


If you are looking for some good placed to read about this: Look at J.D. 
Ralph's book on Piccolo that was mentioned a while ago. There are a lot to 
gain about how to perform sync. Another good one in the paper by Chadwick 
and Springett in IEEE Trans. Comm Vol 18(#6) December 1970 " The design of 
a low data rate MFSK communication system". They mention two commonly used 
techniques. 


Just a warning about the TI320C50 (applies to the 320C2x as well): beware 
of the REP instruction. If you use that in code that is of any substantial 
time, it can lock out interrupts. The idea in all this stuff is to plan to 
break your code into smaller chunks, some that can be performed in non-time 
critical and others that need to be time critical. Then write a fast, small 
real-time kernel to glue it all together. 


It is often possible to operate a demodulator in non-coherent mode, then let 
your protocol analyser help you achive bit sync, and once you have that, 
close the loop to operate in synchrnous mode. This is what we do with both . 


Anyway, IIR filters are bad news for many reasons - unless you have good 
practical experience - better leave them alone. 


I dont know whether this helps. 


Good Luck and keep us posted. 


73's Johan KC7WW 

From karn@qualcomm.com Thu Jan 19 22:02:16 1995 

Return-Path: <karn@qualcomm. com> 

Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrVAY9-00009WC; Thu, 19 Jan 95 22:02 CST 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id TAA23822; 

Thu, 19 Jan 1995 19:54:09 -0800 

Date: Thu, 19 Jan 1995 19:54:09 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199501200354.TAA23822@servo.qualcomm. com> 

To: esilbaug@afit.af.mil 

CC: hfsig@tapr.org 

In-reply-to: <199501071810.AA08932@stealth.afit.af.mil> (message from Eric E 

Silbaugh on Sat, 7 Jan 95 12:16 CST) 

Subject: Re: [HFSIG:183] Re: HF modulation 


Eric has demonstrated a fairly fundamental and powerful principle of 


statistics: the central limit theorem. That is, if you sum up enough 
independent random variables, eventually you get something that 
approximates a normally (Gaussian) distributed random variable. 


It doesn't really matter what the input distributions are, although if 
the distributions are really non-gaussian it might take more of them 
to approach a gaussian sum. 


The peak-to-average power ratio of a gaussian is of course infinite, 
so you have to pick some maximum level (corresponding to some number 
of standard deviations past the norm) and set your amplifier to clip 
there. If it's high enough, the lost energy will be negligible. 


Phil 

From karn@qualcomm.com Thu Jan 19 22:03:59 1995 

Return-Path: <karn@qualcomm. com> 

Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxVAZo-0001CbC; Thu, 19 Jan 95 22:03 CST 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id UAA23827; 

Thu, 19 Jan 1995 20:05:08 -0800 

Date: Thu, 19 Jan 1995 20:05:08 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199501200405 .UAA23827@servo.qualcomm. com> 

To: larry@owrlakh.unbc.edu 

CC: hfsig@tapr.org 

In-reply-to: <199501072204 .O0AAQ02948@owrlakh.unbc.edu> (message from Larry Gadallah 

on Sat, 7 Jan 95 16:13 CST) 

Subject: Walsh functions reference 


I don't have any references offhand, but they're easy to describe. 
A Hademard matrix: 

is symmetric 

is square 

has a dimension that's a power of 2 

is composed of only Os and 1s 

is defined recursively as follows: 

Hn+1 = }Hn = Hn| 

|Hn ~Hn| 
with, by definition, HO = |0| 


So if you apply this rule, you get 


H1 = 0 0 
0 1 
H2 = 0 0 0 


0) 1 1 0) 
and so forth. 
A Walsh function is simply a row (or column) taken from a Hademard matrix. 


The interesting thing to note about the rows of a Hademard matrix is that 
they're mutually orthogonal. That is, if you pick any two rows at random, 
you'll find that the number of columns in which the two rows agree is equal 
to the number of columns in which they disagree. 


Also, except for the first row, each row has an equal number of Os and 
1s. 


One of the earliest uses for these things was to set up wire crossing 
plans for old open-wire telephone lines to minimize crosstalk. Very 
clever. 


Phil 


From karn@qualcomm.com Fri Jan 20 00:17:37 1995 

Return-Path: <karn@qualcomm. com> 

Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxVC£8-O0001PDC; Fri, 20 Jan 95 00:17 CST 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id WAA23928; 

Thu, 19 Jan 1995 22:14:49 -0800 

Date: Thu, 19 Jan 1995 22:14:49 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199501200614 .WAA23928@servo.qualcomm. com> 

To: shall@rain.org 

CC: hfsig@tapr.org 

In-reply-to: <Pine.SUN.3.90.950109085422 .1092A-100000@coyote.rain.org> (message 

from Stephen Hall on Mon, 9 Jan 95 11:05 CST) 

Subject: Re: [HFSIG:187] Re: G-TOR Booklet 


>Rolf, Regarding G-TOR: I attended a talk given by Phil Anderson regarding 
>G-TOR vs. Pactor and it appeared that G-TOR has much more powerful error 
>correction than Pactor. I would be interested in your evaluation after 
>you have had an opportunity to check it out. Steve, WM6P 


Indeed it does. As I understand it, pactor has xnox error 

correction. All it does is accumulate bit energy across multiple 
transmissions of the same packet. This does increase Eb/NO and hence 

the chance of decoding a packet correctly, but it is much better to 

encode the data first to get some power gain as well as the Eb/NO increase. 


To quantify things, simply sending the same packet twice and then 
combining transmissions increases Eb/NO by 3 dB. Encoding the packet 
in a strong rate 1/2 soft-decision-decoded convolutional code and then 
sending the result in two transmissions not only increases the Eb/NO 
by 3 dB, but also provides up to 7 or 8 dB of coding gain, for a total 


improvement of 10-11 dB. 


G-TOR also uses a Type II Hybrid ARQ/FEC protocol, which I've been 
advocating for some time because of its ability to combine the best of 
FEC (ability to deal with rotten channels) with the best of ARQ 
(adaptability to rapidly changing channel conditions). 


Unfortunately, G-TOR uses a relatively weak code (Golay) and as far as 
I know does hard decision decoding. So the coding gain isn't as great 
as it could be; I think it's only a couple of cB. 


Phil 


From rs@ife.ee.ethz.ch Fri Jan 20 01:23:49 1995 

Return-Path: <rs@ife.ee.ethz.ch> 

Received: from bernina.ethz.ch by dptspd.sat.datapoint.com with smtp 

(Smail3.1.29.1 #5) id mOrVDhB-00014qC; Fri, 20 Jan 95 01:23 CST 

Received: from ife (actually ife-etz.ethz.ch) by bernina.ethz.ch 
with SMTP inbound; Fri, 20 Jan 1995 08:23:23 +0100 

From: Rolf Sommerhalder <rs@ife.ee.ethz.ch> 

Message-Id: <9501200723 .AA04434@ife> 

Received: from ife.ee.ethz.ch (gillespie) by ife.ee.ethz.ch id AA0Q4434; 
Fri, 20 Jan 1995 08:23:22 +0100 

Received: by gillespie.ethz.ch; Fri, 20 Jan 95 08:23:21 +0100 

Subject: Re: [HFSIG:216] Re: G-TOR Booklet 

To: hfsig@tapr.org 

Date: Fri, 20 Jan 95 8:23:20 MET 

In-Reply-To: <199501200614.WAA23928@servo.qualcomm.com>; from "Phil Karn" at Jan 

20, 95 12:20 am 

content-length: 2041 


> ...As I understand it, pactor has *nox error 
> correction. All it does is accumulate bit energy across multiple 
> transmissions of the same packet. 


Yes, this is correct; Pactor uses a simple Memory-ARQ protocol without 
any error-correction coding (i.e. it is not a hybrid protocol at all). 


G-TOR also uses a Type II Hybrid ARQ/FEC protocol, which I've been 
advocating for some time because of its ability to combine the best of 
FEC (ability to deal with rotten channels) with the best of ARQ 
(adaptability to rapidly changing channel conditions) . 


Unfortunately, G-TOR uses a relatively weak code (Golay) and as far as 
I know does hard decision decoding. So the coding gain isn't as great 
as it could be; I think it's only a couple of cB. 


VVVVVV VV 


I was involved in developing an HF-modem over the last 4 years 

or so. Unfortunately it never made it to the market :-( 

It employed such an adaptive Memory Type II Hybrid ARQ/FEC protocol on top of 
a constant-envelope offset QPSK modulation. The memory-ARQ was augemented by 


a kind of Chase' code-combining using convolutional-codes for error-correction. 
Indeed, this modem allowed us to adapt over a wide range of signal-to-noise 
ratios and achieved still some bit/s throughput at an SNR of -20 dB (measured at 
3 kHz bandwidth), whereas all other modems I tested stop working at around -9 dB. 
So this confirms Phil's estimate of a 10-11 dB gain. 


The GTOR booklet should be on its way to HB9... 


73, 
Rolf 


ee a a 


Rolf Sommerhalder 
Swiss Federal Institute of Technology (ETH) home address: 


Electronics Laboratory ETZ H60.1 c/o Rindlisbacher 
Gloriastrasse 35 Wermatswilerstrasse 96 

8092 Zurich / Switzerland 8610 Uster / Switzerland 
Voice +41 1 632 76 40 (or 632 51 53) Voice +41 1 941 59 28 

Fax +41 1 632 12 10 AX.25 HB9CWP @ HB90S 

E-Mail rolf.sommerhalder@ife.ee.ethz.ch Swiss Disaster Relief HBK81 


From FORRERJ@frl.orst.edu Fri Jan 20 11:12:33 1995 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrVMsv-OOOO0PC; Fri, 20 Jan 95 11:12 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAA20903 for <hfsig@tapr.org>; Fri, 20 Jan 1995 
01:50:24 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Fri, 20 Jan 95 9:10:52 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Fri, 20 Jan 95 9:10:29 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Fri, 20 Jan 1995 09:10:22 PST8PDT 
Subject: Re: [HFSIG:214] Re: HF modulation 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <E392A520687@frl.orst.edu> 
Hi All, 


As I gain more working experince with these composite audio signals, I 
don't think we should, as Phil suggested, break our heads too much about 
the poor crest factor. In my 8-channel system, I scaled the RMS value way 
down so that the dynamic range of the D/A can gandle the peaks. Playing the 
audio through the speaker amp, it sounds quite clean - nothing adverse to 
report at all. Actually, if one look at a sound clip on the Windows sound 


editor, it also shows some poor crest factor - though thats quite normal 
for everyday sounds. 


Now here is the challenge for you technical types: Could someone (Al, 
Barry) explain what it would take in terms of linear amps etc, to be able 
to use this waveform, i.e. if one say have the rms level set at 1W output, 
and expect some 18 dB peaks, what should the RF amp have to deliver to pass 
the peaks. I know its simple math, but just for everyones curiosity. Thanks 
fellows. 


73's 


Johan, KC7WW 
From kchen@apple.com Fri Jan 20 12:09:36 1995 
Return-Path: <kchen@apple.com> 
Received: from apple.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxVNm2-OOQOOHNC; Fri, 20 Jan 95 12:09 CST 
Received: by apple.com (5.61/8-Oct-1993-eef) 
id AAQ8031; Fri, 20 Jan 95 10:08:46 -0800 
for hfsig@tapr.org 
Date: Fri, 20 Jan 95 10:08:46 -0800 
From: Kok Chen <kchen@apple. com> 
Message-Id: <9501201808 .AAQ8031@apple. com> 
To: hfsig@tapr.org 
Subject: Hadamard matrices 


Just a small correction on Phil's posting. Hadamard is spelled with 
an "a" after the "d," not an "“e." 

Also, Hadamard matrices do not have to be a power of 2. The neccessary 
condition is that the order is 2, or a multiple of 4. Not all multiples 
of 4 can exist. The first number where the condition is insufficient is 
order 188. See Berlekamp's Algebraic Coding Theory book for a discussion. 
(McGraw-Hill, 1968 - my copy predates the ISBN numbering, sorry). 


One of the nice properties of Hadamard matrices which Phil did not mention 
is that the inverse of a Hadamard matrix is its own transpose scaled by 
the order of the matrix. This makes taking the inverse transform as easy 
as doing the forward transform. 


(Hadamard is more well known for the "Hadamard Inequality" regarding the 
relationship between the determinant of a square matrix and the square 
magnitude of its elements.) 


See Robert McEliece, "The Theory of Information and Coding," Addison 

Wesley, 1977, ISBN 0-201-13502-7 for a reference to the fact that the 
best block codes with a certain distance property are all related to 

the Hadamard matrix. 


Finally, I'm not sure which came first - Rademacher-Walsh functions or 
Hadamard matrices. Both Walsh and Hadamard were contemporaries during 
the early 1900s. I need to ask some mathematician friends about that. 


73 


Kok Chen, AA6TY kchen@apple.com 

Apple Computer, Inc. 

From karn@qualcomm.com Fri Jan 20 16:33:27 1995 

Return-Path: <karn@qualcomm. com> 

Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrVRtU-QOQ00SGC; Fri, 20 Jan 95 16:33 CST 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id OAA03393; 

Fri, 20 Jan 1995 14:35:24 -0800 

Date: Fri, 20 Jan 1995 14:35:24 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199501202235.0AA03393@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <9501200723.AA04434@ife> (message from Rolf Sommerhalder on Fri, 20 

Jan 95 01:39 CST) 

Subject: Re: [HFSIG:217] Re: G-TOR Booklet 


I just checked my references. Hard decision Extended Golay (24,12) 
over a BPSK or QPSK AWGN channel has a gain of about 2.5 dB at 
BER=1e-5. As expected, soft decision decoding buys another 2dB for a 
total of 4.5dB. 


Convolutional codes can do much better at the same rate of 1/2. K=7 
soft Viterbi decoded can give about 5.5-6.0 dB, and going to K=9 gives 
6.0-6.5dB. (All at a BER of 1e-5). K=32 soft Fano (sequential) 
decoded gives about 7-7.5 dB of gain. 


Phil 
From FORRERJ@frl.orst.edu Fri Jan 20 19:03:42 1995 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxVUEu-00018uC; Fri, 20 Jan 95 19:03 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id JAA24576 for <hfsig@tapr.org>; Fri, 20 Jan 1995 
09:41:34 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Fri, 20 Jan 95 17:02:03 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Fri, 20 Jan 95 17:01:44 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERIJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Fri, 20 Jan 1995 17:01:40 PST8PDT 
Subject: Re: [HFSIG:220] Re: G-TOR Booklet 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <E41053C7F24@frl.orst.edu> 


Hi Phil, 


Those figures for coding gain on Golay that you mentioned, does it account 
for interleaving? In the Pierce paper they show that an effective 
constraint factor, i.e. high order of interleaving, in the order of 5000 - 
50000 bits, used with the perfect codes (23,12,3) (Golay) and (127,64,10) 
works as well as any of the convolutional codes they tested, including 
concatenated convoltutional - block codes. What am I missing - are these 
figures of merit apples and oranges? HELP! 


Could you also perhaps give us some feedback on what kind of resolution 
would you need on the soft decision decoding (how many levels) would be 
practical, i.e. 16 bits would produce a very large trellis would'nt it? Is 
4 levels sufficient? 


Keep up the good work. 
73's 


Johan, KC7WW 

From karn@qualcomm.com Fri Jan 20 20:40:21 1995 

Return-Path: <karn@qualcomm. com> 

Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxVVkQ-0001L2C; Fri, 20 Jan 95 20:40 CST 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id SAAQ3627; 

Fri, 20 Jan 1995 18:42:24 -0800 

Date: Fri, 20 Jan 1995 18:42:24 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199501210242 .SAAQ3627@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <E41053C7F24@frl.orst.edu> (FORRERJ@frl.orst.edu) 

Subject: Re: [HFSIG:221] Re: G-TOR Booklet 


>Those figures for coding gain on Golay that you mentioned, does it account 
>for interleaving? In the Pierce paper they show that an effective 


Interleaving is a no-op on the AWGN channel. The error distribution is 
already uniformly random, so interleaving doesn't make any difference. 


Of course, HF is *not*x an AWGN channel. So interleaving can make a big 
difference there, as it does on the mobile fading channel. 


Also, when you concatenate codes the channel seen by the outer code is 
decidedly non-AWGN even if the physical channel seen by the inner code 
is AWGN. For example, Voyager used Reed-Solomon over Viterbi, and 
Viterbi decoding errors generally occur in characteristic bursts until 
the decoder eventually resettles on the correct path through the 
trellis. Interleaving spread out these bursts over multiple RS blocks, 
making them easier to correct. 


Phil 

From FORRERJ@frl.orst.edu Sat Jan 21 15:34:50 1995 

Return-Path: <FORRERJ@frl.orst.edu> 

Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxVnSI-000045C; Sat, 21 Jan 95 15:34 CST 


Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id GAA27134 for <HFSIG@tapr.org>; Sat, 21 Jan 1995 
06:12:38 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Sat, 21 Jan 95 13:33:09 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Sat, 21 Jan 95 13:32:55 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Sat, 21 Jan 1995 13:32:50 PST8PDT 
Subject: Eval copy of parallel modem 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <E558AE51424@frl.orst.edu> 
Hi folks, 


I will place an evaluation copy of the parallel modem on the net on 
monday. The modem runs in real time on a PSA sound card - I have tested it 
on my Orchid Soundwave32 and will also test it on a Cardinal card over the 
weekend. 


This is only a test setup but I am sure you will find it interesting. The 
PC host sends a test message over the 8-channel OFDM modem that runs on 

the DSP on the sound card and plays the demodulated message as received 
from the modem, on the screen. You will hear the tones going over the 
speaker and see the rate that it writes to the screen. This version 
occupies only 250 Hz, so you could multiply things by four to get a felling 
of what is coming, of course it will be slower once we add the error- 
correcting code. 


The next task is to work on the synchroniser and then the data-link layer. 
Then we will be able to start testing over the air. 


I dont have FTP capability here from home, else would have put it on the 
net already. Look for the code monday at ftp.ucsd.edu in 
/hamradio/packet/tcpip/incoming/pmodem1. zip 

I will include a short readme to help you set it up and run it. 


73's 
Johan, KC7WW 


From rs@ife.ee.ethz.ch Mon Jan 23 01:10:13 1995 
Return-Path: <rs@ife.ee.ethz.ch> 
Received: from bernina.ethz.ch by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxWIuf-O0009VC; Mon, 23 Jan 95 01:10 CST 
Received: from ife (actually ife-etz.ethz.ch) by bernina.ethz.ch 
with SMTP inbound; Mon, 23 Jan 1995 08:10:02 +0100 
From: Rolf Sommerhalder <rs@ife.ee.ethz.ch> 


Message-Id: <9501230710.AA05321@ife> 
Received: from ife.ee.ethz.ch (gillespie) by ife.ee.ethz.ch id AAQ5321; 
Mon, 23 Jan 1995 08:10:00 +0100 
Received: by gillespie.ethz.ch; Mon, 23 Jan 95 08:09:59 +0100 
Subject: Re: [HFSIG:221] Re: G-TOR Booklet 
To: hfsig@tapr.org 
Date: Mon, 23 Jan 95 8:09:59 MET 
In-Reply-To: <E41053C7F24@frl.orst.edu>; from "Johan Forrer FL" at Jan 20, 95 7:06 
pm 
content-length: 1659 


Johan wrote: 

Could you also perhaps give us some feedback on what kind of resolution 
would you need on the soft decision decoding (how many levels) would be 
practical, i.e. 16 bits would produce a very large trellis would'nt it? Is 
4 levels sufficient? 


Vv 


VV WV 


I should dig out a reference about this question which provides you with 

exact graphs how much you loose/gain by decreasing/increasing the number 

of quantization levels. 

My own experience is that 256 level quantization (i.e. 8 bit) is fine, but 

8 level quantization still works and the losses (versus 256 level quantization) 
are around 1/8 to 1/4 dB (if I recall thouse figures correctly). However, 

the performance of a 8 level quantized Viterbi decoder is heavily dependend 

on the correct setting of the quantization thresholds/levels, i.e. a 

perfectly adapted AGC is a must. The more quanitzation levels you spend 

in the decoder, the looser your gain control may be. 


73, 
Rolf 


P.S. Most of the commercial Viterbi decoder chips available work with 3-bit 
(plus additional erasure symbol) or 3.5- or 4-bit quantization. 
ee a a 


Rolf Sommerhalder 
Swiss Federal Institute of Technology (ETH) home address: 


Electronics Laboratory ETZ H60.1 c/o Rindlisbacher 
Gloriastrasse 35 Wermatswilerstrasse 96 

8092 Zurich / Switzerland 8610 Uster / Switzerland 
Voice +41 1 632 76 40 (or 632 51 53) Voice +41 1 941 59 28 

Fax +41 1 632 12 10 AX.25 HB9CWP @ HB9OS 

E-Mail rolf.sommerhalder@ife.ee.ethz.ch Swiss Disaster Relief HBK81 


From FORRERJ@frl.orst.edu Mon Jan 23 11:03:05 1995 

Return-Path: <FORRERJ@frl.orst.edu> 

Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxWSAQ-0000sbC; Mon, 23 Jan 95 11:03 CST 

Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 

(8.6.9/8.6.9) with SMTP id BAAOO382 for <hfsig@tapr.org>; Mon, 23 Jan 1995 


01:42:17 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Mon, 23 Jan 95 9:00:52 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 23 Jan 95 9:00:25 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERIJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 23 Jan 1995 09:00:23 PST8PDT 
Subject: Re: [HFSIG:217] Re: G-TOR Booklet 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <E8101787ACB@frl.orst.edu> 
Rolf Sommerhalder wrote: 
<...lines deleted...> 


> I was involved in developing an HF-modem over the last 4 years 

> or so. Unfortunately it never made it to the market :-( 

> It employed such an adaptive Memory Type II Hybrid ARQ/FEC protocol on 
top of 

> a constant-envelope offset QPSK modulation. The memory-ARQ was augemented 
by 

> a kind of Chase’ code-combining using convolutional-codes for error- 
correction. 

> Indeed, this modem allowed us to adapt over a wide range of signal-to- 
noise 

> ratios and achieved still some bit/s throughput at an SNR of -20 dB 
(measured at 

> 3 kHz bandwidth), whereas all other modems I tested stop working at 
around -9 cB. 

> So this confirms Phil's estimate of a 10-11 dB gain. 


Sounds like a nice accomplishment - congratatulations! Have you though 
about publishing something about it? I am sure we all would be very 
interested learning more about it. OQPSK has a very nice and clean 
waveform - I will look into that a little more. What kind of DSP is 
this work based on? 


I have been using 16-bit soft-decoding Memory-ARQ on the sound card 
implementation of Pactor and have found it to help quite a bit - a bit 
better than nothing at all. 

73's 

Johan, KC7WW 

From FORRERJ@frl.orst.edu Mon Jan 23 11:07:04 1995 


Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 


(Smail3.1.29.1 #5) id mOxWSEH-Q001KqC; Mon, 23 Jan 95 11:07 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAAOO598 for <hfsig@tapr.org>; Mon, 23 Jan 1995 
01:46:47 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Mon, 23 Jan 95 9:05:21 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 23 Jan 95 9:05:02 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 23 Jan 1995 09:04:52 PST8PDT 

Subject: Re: [HFSIG:223] Eval copy of parallel modem 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <E81152C3BC6@frl.orst.edu> 
Hi all, 
The files are now on ftp.ucsd.edu. 


I would like to thank OM Kok Chen, AA6TY for the wonderful 
discussions we have had on how to make this parallel modem work. 


73's 
Johan, KC7WW 


From esilbaug@afit.af.mil Mon Jan 23 16:55:18 1995 

Return-Path: <esilbaug@afit.af.mil> 

Received: from stealth.afit.af.mil by dptspd.sat.datapoint.com with smtp 

(Smail3.1.29.1 #5) id mOxWXf£H-OOO1MtC; Mon, 23 Jan 95 16:55 CST 

Received: from grouse.afit.af.mil by stealth.afit.af.mil with SMTP id AA28813 
(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Mon, 23 Jan 1995 17:53:53 -0500 

Date: Mon, 23 Jan 1995 17:53:53 -0500 

From: Eric E Silbaugh <esilbaug@afit.af.mil> 

Message-Id: <199501232253.AA28813@stealth.afit.af.mil> 

To: bm@lynx.ve3jf£.ampr.org 

Subject: RE: HF Modulation 

Cc: hfsig@tapr.org 


Barry, 


Thanks for the references! They just added to my depression :) 
Seriously, it's nice to see that my conjecture wasn't too far 
off the mark. They answer some of the questions I asked and 
confirm that the problem is difficult. 


In my simulations I was thinking in terms of power not voltage so 
I used 10*log() not 20*log(). This is the source of the factor of 
2 difference in our crest factor calculations. I probably should 


have been more specific; others were confused by this as well. 


I tracked down the papers you mentioned and gave them a quick 
reading. Boyd considers a sum of equally spaced sinusoids and 
Shlien considers a sum of sinusoids with arbitrary frequency 
spacing (I think). Our case seems to be in between with a set 
of equally spaced sinusoids but not all are present. 


It was encouraging to see that limits on crest factor reduction 
are nearly independent of the number of sinusoids. This means the 
Walsh functions will control how well a particular set of phases 
works. I'm going to try the quadratic initial phase scheme from 
the Boyd paper and see what it does. 


Both authors found that using numerical methods to reduce the crest 
factor is difficult because the minimizing function has many local 
minima. It seems possible to get significant reductions in the 
crest factor, but there is no known optimal method. The hopeful 
note was Shlien's results showing that most of the local minima are 
pretty good. 


I am not familiar with the linear programming methods Shlien used. 
What methods did your colleague use? 


Thanks again for the answers, now I've got even more questions! 


Eric, N2NNP 


He a a Eric E. Silbaugh 
: carne esilbaug@afit.af.mil 


oe es All standard, non-standard, and 

MRS ERS Ss ete Ses MIL-STD disclaimers apply 
From karn@qualcomm.com Mon Jan 23 22:34:29 1995 
Return-Path: <karn@qualcomm. com> 
Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp 

(Smail3.1.29.1 #5) id mOxWcxW-0001aAC; Mon, 23 Jan 95 22:34 CST 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id UAA01968; 
Mon, 23 Jan 1995 20:36:36 -0800 
Date: Mon, 23 Jan 1995 20:36:36 -0800 
From: Phil Karn <karn@qualcomm. com> 
Message-Id: <199501240436 .UAA01968@servo.qualcomm. com> 
To: hfsig@tapr.org 
In-reply-to: <9501230710.AA05321@ife> (message from Rolf Sommerhalder on Mon, 23 
Jan 95 01:24 CST) 
Subject: Re: [HFSIG:224] Re: G-TOR Booklet 


Rolf is quite right about most commercial Viterbi decoders using 3-bit 
symbols (8 levels). Qualcomm's chips do this, and it seems to be 
standard practice. It's enough to get you within a fraction of a dB of 
the theoretical limit for infinite quantization. The chip area you 


save with narrower data paths can instead be spent on having more 
add-compare-select units to allow longer constraint lengths, a net 
performance gain. 


Of course, in software there's no particular reason to use smaller 
samples since you already have wide data paths in your CPU that you 
might as well use. 


Correct gain settings is important, but Viterbi decoders are 
Significantly more robust than sequential decoders in this 

respect. Ideally you want to set your gains on noise alone for both 
types of decoders, but real AGCs respond to the sum of signal plus 
noise so the tracking isn't exact. 


We (Qualcomm) have an ap note on this precise topic that derives the 
correct gain setting as a function of noise and shows the degradation 
in required Eb/NO as a function of AGC error. It's quite small for 
about a 6dB range around the correct level, then rises rapidly outside 
that. 


Fortunately, due to the steepening of the waterfall curve with coding 
you really only have to get the gain right at the nominal Eb/NO. A 
weaker signal would be too weak to decode even with a correct gain, 
and a strong signal will decode correctly even with a large gain 
error. 


I said that sequential decoders are less robust to gain 
misadjustments. Much of the early literature (there's been a 
noticeable dropoff in sequential decoding papers since the late 60s 
when the Viterbi algorithm came out) talks about avoiding the problem 
by using hard decision decoding. The long-constraint length (K>=32) 
codes generally used in sequential decoding are so strong that they 
make up for much of the 2dB you lose with hard decision coding. 


But I don't want to give up that 2dB without a fight. Getting soft 
decision decoding to work really well in my protocol, especially with 
non-Gaussian noise, may take some doing. 


Phil 


From esilbaug@afit.af.mil Tue Jan 24 08:08:31 1995 

Return-Path: <esilbaug@afit.af.mil> 

Received: from stealth.afit.af.mil by dptspd.sat.datapoint.com with smtp 

(Smail3.1.29.1 #5) id mOxWluz-00010sC; Tue, 24 Jan 95 08:08 CST 

Received: from dolphin.afit.af.mil by stealth.afit.af£.mil with SMTP id AA08567 
(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Tue, 24 Jan 1995 09:08:23 -0500 

Date: Tue, 24 Jan 1995 09:08:23 -0500 

From: Eric E Silbaugh <esilbaug@afit.af.mil> 

Message-Id: <199501241408.AA08567@stealth.afit.af.mil> 

To: hfsig@tapr.org 

Subject: RE: HF Modulation 


Barry, 


Thanks for the references! They just added to my depression :) 
Seriously, it's nice to see that my conjecture wasn't too far 
off the mark. They answer some of the questions I asked and 
confirm that the problem is difficult. 


In my simulations I was thinking in terms of power not voltage so 
I used 10*log() not 20*log(). This is the source of the factor of 
2 difference in our crest factor calculations. I probably should 
have been more specific; others were confused by this as well. 


I tracked down the papers you mentioned and gave them a quick 
reading. Boyd considers a sum of equally spaced sinusoids and 
Shlien considers a sum of sinusoids with arbitrary frequency 
spacing (I think). Our case seems to be in between with a set 
of equally spaced sinusoids but not all are present. 


It was encouraging to see that limits on crest factor reduction 
are nearly independent of the number of sinusoids. This means the 
Walsh functions will control how well a particular set of phases 
works. I'm going to try the quadratic initial phase scheme from 
the Boyd paper and see what it does. 


Both authors found that using numerical methods to reduce the crest 
factor is difficult because the minimizing function has many local 
minima. It seems possible to get significant reductions in the 
crest factor, but there is no known optimal method. The hopeful 
note was Shlien's results showing that most of the local minima are 
pretty good. 


I am not familiar with the linear programming methods Shlien used. 
What methods did your colleague use? 


Thanks again for the answers, now I've got even more questions! 


Eric, N2NNP 


a ee os Eric E. Silbaugh 
: ae hs esilbaug@afit.af.mil 


ee nS All standard, non-standard, and 
Met TROL ESET Res eee MIL-STD disclaimers apply 

From muphaus@cris.com Tue Jan 24 22:19:46 1995 

Return-Path: <Muphaus@cris.com> 

Received: from cris.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrWzCq-OO000EaC; Tue, 24 Jan 95 22:19 CST 

Received: from voyager.cris.com by cris.com [1-800-745-CRIS (voice) ] 

Received: by voyager.cris.com (4.1/SMI-4.1) 
id AA22606; Tue, 24 Jan 95 23:18:58 EST 


To: hfsig@tapr.org 

Cc: forrerj@frl.orst.edu 

From: muphaus@cris.com (Marv Uphaus) 

Subject: Re: [HFSIG:223] Eval copy of parallel modem 
Date: Tue, 24 Jan 1995 23:53:16 -0600 

Organization: Not Organized 

Reply-To: muphaus@cris.com 

Message-Id: <CTU91CysSc7P077yn@cris.com> 
In-Reply-To: <E558AE51424@frl.orst.edu> 

Lines: 23 


On Sat, 21 Jan 95 15:38 CST, "Johan Forrer FL" <FORRERIJ@frl.orst.edu> wrote: 


>I will place an evaluation copy of the parallel modem on the net on 
>monday. The modem runs in real time on a PSA sound card - I have tested it 
>on my Orchid Soundwave32 and will also test it on a Cardinal card over the 
>weekend. 


Johan, and All... 


I FTPed the file and ran it and all I can say is keep going... It looks 
(and sounds) good... One note... The SW32 has a load feature that allows 
you to load the driver... Just do a "SW32 /F:parll.ld" and then run 
MODEM... 

Johan, what are the clicks... I distinctly hear tones but also some low 
frequency "clicks"... Us novices want to know... ;-) 

Marv... 

-- Marv Uphaus -- muphaus@cris.com -- Ph: 334-343-9256 -- 

-- U.S.Mail: 4031 Airport Blvd. #49 -- Mobile, AL 36608 -- 

-- Packet Radio Address -- K4BVG @W4IAX.#MOBAL.AL.USA.NA -- 


From esilbaug@afit.af.mil Wed Jan 25 15:20:52 1995 

Return-Path: <esilbaug@afit.af.mil> 

Received: from stealth.afit.af.mil by dptspd.sat.datapoint.com with smtp 

(Smail3.1.29.1 #5) id mOrXF8N-0000mIC; Wed, 25 Jan 95 15:20 CST 

Received: from grouse.afit.af.mil by stealth.afit.af.mil with SMTP id AA14845 
(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Wed, 25 Jan 1995 16:20:39 -0500 

Date: Wed, 25 Jan 1995 16:20:39 -0500 

From: Eric E Silbaugh <esilbaug@afit.af.mil> 

Message-Id: <199501252120.AA14845@stealth.afit.af.mil> 

To: hfsig@tapr.org 

Subject: Crest Factor Control 

Cc: esilbaug@afit.af.mil 


This is a toothpaste commercial, NOT! 


WHY CREST FACTOR CONTROL 


Thus wrote Johan, KC7WW: 


> Actually, if one look at a sound clip on the Windows sound editor, it 
> also shows some poor crest factor - though thats quite normal for 
> everyday sounds. 


Speech is well known as a 'peaky' (high crest factor) signal, thus the 
voice processors (peak clipping) used by DXers. The other extreme is 
RTTY overheating a linear amp; higher average power. 


Thus wrote Barry, VE3JF: 


>> - Is reducing the peak-to-RMS ratio really as 
>> important as I seem to think it is? 


> 
> I'd say it's certainly worth further investigation... with the 

> processing power now available in DSP's, control of the CF seems a lot 
> more feasible than it used to be. Sometimes higher average power will 
> buy you an improvement in BER, and sometimes it won't (when you've hit 
> an irreducible error rate due to intersymbol interference from 

> multipath), but overall it would be a win. 


Johan also enscribed: 


> As I gain more working experince with these composite audio signals, I 
> don't think we should, as Phil suggested, break our heads too much 
> about the poor crest factor. 


I have to agree. High crest factors are not a ‘show stopper’ but will 
make using multitone modems more difficult. Likewise, low crest factors 
will lower the peak instantaneous power which should reduce interference; 
they are not a cure-all. 


If we control the crest factor we can get more energy per symbol, for 
the same input signal level. Low crest factor signals will also reduce 
the chances of accidentally overdriving an amplifier. This would make 
the modem easier to use, which would be a real benefit. How much more 
energy and how much easier to use are open questions. 


We need not worry about getting the absolute lowest crest factor; 
instead, let's concentrate on controlling the crest factor to a 
reasonable value. In the paper Barry mentioned, Boyd was developing 
multitone test equipment and notes that crest factors of 6 dB are 
acceptable for many applications. We can get a basic proof-of-concept 
modem running, begin testing, and then refine it. 


WHERE TO GO FROM HERE 


Since we are talking about M-ary signaling it should be feasible to use 
numerical or empirical methods to find sets of phases to minimize the 
crest factor for each signal, as long as M is a reasonable number. Monte 
Carlo methods will probably be useful (pun intended). 


Looking towards an implementation, if we stay with incoherent 
demodulation we may not have to standardize which phases to use. Just 
choose any set of phases giving reasonable crest factors; the magnitude 
spectrum will be unchanged. It would be good to provide a standard set 
so not everyone has to go through the minimization process. Who knows, 
there may be patterns which could lead to an empirical algorithm for 
choosing a good set of phases; if not, we could use a look-up table to 
set the initial phases. 


Johan sent me some information that suggests the crest factor may not be 
preserved during SSB modulation. This would not be good. We must 
ensure crest factor controlled signals are robust under SSB modulation, 
and passband filtering distortions. I will try to incorporate SSB 
modulation into my simiulation and see what happens. 


SIMULATIONS 


Some late-breaking news on my MATLAB simulations of Phil's proposal for 
using Walsh functions. I implemented the method outlined in the Boyd 
paper. Basically, it involves putting a quadratic initial phase on each 
sinusoid. In other words, the first sinusoid has zero phase and the 
initial phase of the other sinusoids increases as the square of the 
distance, in frequency, from the first. 


Using 20xlog(peak/RMS), the crest factor for the zero phase case is 18 
dB. With quadratic initial phase the crest factor is between 7-8 dB. 
Simulation of 20 different signals gave an average of 7.52 dB. That's 
10 dB less than the zero phase case and may be good enough! Many of the 
Signals looked like chirp signals, just like the examples in the Boyd 
paper. In a few cases my naive random initial phase method produced a 
slightly lower crest factor. This was very rare; in most cases the 
random method was 1-2 dB higher. 


ALMOST FINISHED 


Multitone signaling, OFDM, is one of several solutions we should 
evaluate. From a system view it has some attractive features: multiple 
tones combat selective fading caused by multipath, and M-ary signaling 
reduces the effects of inter-symbol interference. Channel coding to 
correct errors and automatic power control will probably also be part 
of any robust, low interference HF modem. However, we can start simple 
and add complexity only when necessary. 


Eric, N2NNP 


as Had te Eric E. Silbaugh 
; nee esilbaug@afit.af.mil 


: ae All standard, non-standard, and 
SS RICE SS Te Sebi MIL-STD disclaimers apply 
From FORRERJ@frl.orst.edu Mon Jan 30 11:18:47 1995 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrYzkS-Q00QUeC; Mon, 30 Jan 95 11:18 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAA10493 for <hfsig@tapr.org>; Mon, 30 Jan 1995 
01:57:36 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Mon, 30 Jan 95 9:18:12 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 30 Jan 95 9:17:51 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 30 Jan 1995 09:17:47 PST8PDT 
Subject: Re: [HFSIG:231] Crest Factor Control 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <8A5E586F7A@frl.orst.edu> 
Eric Silbaugh wrote: 


<...lines...deleted> 


Looking towards an implementation, if we stay with incoherent 
demodulation we may not have to standardize which phases to use. Just 
choose any set of phases giving reasonable crest factors; the magnitude 
spectrum will be unchanged. It would be good to provide a standard set 
so not everyone has to go through the minimization process. Who knows, 
there may be patterns which could lead to an empirical algorithm for 
choosing a good set of phases; if not, we could use a look-up table to 
set the initial phases. 


VV VV VV VV 


Good suggestion Eric - this looks like the way we should do it. 


I only wish that there was some solution for QPSK. It appears that 
offset PSK is one possibility, perhaps waveshaping similar to 
generate MSK waveforms - may help to produce a constant envelope? 

I will be playing with that idea a bit more when I get a bit of time. 
Does anyone know how this is done on the Harris 39-tone modems? 


73's 


Johan - KC7WW 

From FORRERJ@frl.orst.edu Mon Jan 30 18:02:50 1995 

Return-Path: <FORRERJ@frl.orst.edu> 

Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrZ63T-O00000qC; Mon, 30 Jan 95 18:02 CST 


Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id IAA13890 for <HFSIG@tapr.org>; Mon, 30 Jan 1995 
08:42:04 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Mon, 30 Jan 95 16:02:45 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 30 Jan 95 16:02:22 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERIJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Mon, 30 Jan 1995 16:02:15 PST8PDT 
Subject: Packet software for sound card 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <911C7750DB@frl.orst.edu> 
Hi All, 
This does not really belong in the HFSIG - just for those interested. 


I have put the HB9JNX sound card modem software on the "upload" directory. 
This is Thomas Sailer's 1200 and 9600 (G3RUH compatible) DSP modems 

for PSA sound cards. Assuming you know how to integrate such 

software into one of the "NOS" flavors, things will make sense. 


Tom also has a neat RTTY/AMTOR/Pactor package that uses the sound 
card for his DSP modem - scalable tones, FFT display etc. I will upload 
that as well. 


Thanks to Tom for making his software available. 
73's 


Johan, KC7WW 

From muphaus@cris.com Tue Jan 31 00:48:55 1995 

Return-Path: <Muphaus@cris.com> 

Received: from cris.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrZCOT-Q0005bC; Tue, 31 Jan 95 00:48 CST 

Received: from voyager.cris.com by cris.com [1-800-745-CRIS (voice) ] 

Received: by voyager.cris.com (4.1/SMI-4.1) 
id AA17624; Tue, 31 Jan 95 01:48:02 EST 

To: hfsig@tapr.org 

From: muphaus@cris.com (Marv Uphaus) 

Subject: Re: [HFSIG:233] Packet software for sound card 

Date: Mon, 30 Jan 1995 22:24:34 -0600 

Organization: Not Organized 

Reply-To: muphaus@cris.com 

Message-Id: <2kRB1CysSgj3077yn@cris.com> 

In-Reply-To: <911C7750DB@frl.orst.edu> 

Lines: 28 


On Mon, 30 Jan 95 18:06 CST, "Johan Forrer 


FL" <FORRERIJ@frl.orst.edu> wrote: 


>Tom also has a neat RTTY/AMTOR/Pactor package that uses the sound 
>card for his DSP modem - scalable tones, FFT display etc. I will upload 
>that as well. 


I got Tom's software last week, Johan, and it seems to work quite well... 
What it doesn't do is reset the PSA card back properly... Nothing I could 
do would set the PSA card back properly for WinDOZ... It wouldn't reload 
the VSW32.386 driver properly... Only turning the computer off and back on 
would reset the card... 


Tom, are you reading this...??? Anybody know a fix for this or is it a 
coding problem in the exit from the DSP software... I do, of course, know 
to reload the GENMID.LD driver... That seemed to go OK, but WinDOZ would 
never load the VSW32.386 driver until the computer was turned off and on 
again... 


>Thanks to Tom for making his software available. 


You bet, Tom... Nice...!!! 

Marv... 

-- Marv Uphaus -- muphaus@cris.com -- Ph: 334-343-9256 -- 
-- U.S.Mail: 4031 Airport Blvd. #49 -- Mobile, AL 36608 -- 
-- Packet Radio Address -- K4BVG @W4IAX.#MOBAL.AL.USA.NA_ -- 


From FORRERJ@frl.orst.edu Tue Jan 31 10:40:49 1995 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrZLdG-0000coC; Tue, 31 Jan 95 10:40 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAA17018 for <hfsig@tapr.org>; Tue, 31 Jan 1995 
01:20:04 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Tue, 31 Jan 95 8:40:44 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 31 Jan 95 8:40:28 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Tue, 31 Jan 1995 08:40:24 PST8PDT 

Subject: Re: [HFSIG:234] Re: Packet software for sound card 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <A1BF76523B@frl.orst.edu> 
Hi Marv, 


I have E-mailed to Tom and will post the new version in the upload area. 
Will let you know. 


For those interested, I will post my spectral display program for the PSA 
cards in the upload area. It works, though is nothing fancy - just a 
passing milestone during the OFDM research. look for FFTSCOP.ZIP. 

73's 


Johan, KC7WW 


